On 17/01/2002 07:34:05 Herold Heiko wrote: [proper order restored] >> -----Original Message----- >> From: Hrvoje Niksic [mailto:[EMAIL PROTECTED]] >> Sent: Thursday, January 17, 2002 2:15 AM >> To: Michael Jennings >> Cc: [EMAIL PROTECTED] >> Subject: Re: Bug report: 1) Small error 2) Improvement to Manual >> >> >> Michael Jennings <[EMAIL PROTECTED]> writes: >> >> > 1) There is a very small bug in WGet version 1.8.1. The bug occurs >> > when a .wgetrc file is edited using an MS-DOS text editor: >> > >> > WGet returns an error message when the .wgetrc file is terminated >> > with an MS-DOS end-of-file mark (Control-Z). MS-DOS is the >> > command-line language for all versions of Windows, so ignoring the >> > end-of-file mark would make sense. >> >> Ouch, I never thought of that. Wget opens files in binary mode and >> handles the line termination manually -- but I never thought to handle >> ^Z. >> >> As much as I'd like to be helpful, I must admit I'm loath to encumber >> the code with support for this particular thing. I have never seen it >> before; is it only an artifact of DOS editors, or is it used on >> Windows too? >>
[snip "copy con file.txt"] > >However in this case (at least when I just tried) the file won't contain >the ^Z. OTOH some DOS programs still will work on NT4, NT2k and XP, and >could be used, and would create files ending with ^Z. But do they really >belong here and should wget be bothered ? > >What we really need to know is: > >Is ^Z still a valid, recognized character indicating end-of-file (for >textmode files) for command shell programs on windows NT 4/2k/Xp ? >Somebody with access to the *windows standards* could shed more light on >this question ? > >My personal idea is: >As a matter of fact no *windows* text editor I know of, even the >supplied windows ones (notepad, wordpad) AFAIK will add the ^Z at the >end of file.txt. Wget is a *windows* program (although running in >console mode), not a *Dos* program (except for the real dos port I know >exists but never tried out). > I don't think there's a distinction between DOS and Windows programs in this regard. The C runtime library is most likely to play a significant role here. For a file fopen-ed in "rt" mode, teh RTL would convert \r\n -> \n and silently eat the _first_ ^Z, returning EOF at that point. When writing, it goes the other way 'round WRT \n->\r\n. I'm unsure about whether it writes ^Z at the end, though. >So personally I'd say it would not be really necessary adding support >for the ^Z, even in the win32 port; except possibly for the Dos port, if >the porter of that beast thinks it would be useful. > Problem could be solved by opening .netrc in "rt" However, the "t" is a non-standard extension. However, this is not wget's problem IMO. Different editors may behave differently. Example: on OS/2 (which isn't a DOS shell, but can run DOS programs), the system editor (e.exe) *does* append a ^Z at the end of every file it saves. People have patched the binary to remove this feature :-) AFAIK no other OS/2 editor does this. -- Csaba Ráduly, Software Engineer Sophos Anti-Virus email: [EMAIL PROTECTED] http://www.sophos.com US Support: +1 888 SOPHOS 9 UK Support: +44 1235 559933
