-
Everyone, In all this discussion, I stay aware of the big picture, which is that WGet is a great program that helps me in my work. I completely accept whatever you decide. The issue is a very minor problem for me, but I can easily re-write an existing filter to strip control-Zs. The problem is due only to a stupid shortcoming in DOS. I use a DOS editor because it has some necessary features that don't exist yet (!) in any GUI editor, either for Windows or Unix. Philosophically, however, I think there is still something to be said. The issue centers, not on the behavior of the program, which can easily be explained. The issue centers on the documentation. Philosophically, in my opinion, a program should be written so the documentation is easy to read. In this case a hidden stripping of useless characters means that there is one less thing to explain in the manual. If the program does not strip Control-Zs, and I were helping with the documentation, I would feel compelled to explain about the possibility for an error message that doesn't actually affect WGet operation. I would hope that the explanation would save someone a few moments of confusion. There is precedent for this. Microsoft Windows is in some places written to get around shortcomings in the processors on which it runs. Such accommodation puts quirkiness in the code, but it gets the job done. Regards, Michael __________________ Hrvoje Niksic wrote: > Michael Jennings <[EMAIL PROTECTED]> writes: > > > However, I have a comment: There is simple logic that would solve > > this problem. WGet, when it reads a line in the configuration file, > > probably now strips off trailing spaces (hex 20, decimal 32). I > > suggest that it strip off both trailing spaces and control > > characters (characters with hex values of 1F or less, decimal values > > of 31 or less). This is a simple change that would work in all > > cases. > > The problem here is that I don't want Wget to randomly strip off > characters from its input. Although the control characters are in > most cases a sign of corruption, I don't want Wget to be the judge of > that. > > Wget currently has clearly defined parsing process: strip whitespaces > at the beginning and end of line, and around the `=' token. Stripping > all the control characters would IMHO be a very random thing to do. > > If I implemented the support for ^Z, I'd only strip it if it occurred > at the end of file, and that's somewhat harder.
