Re: RFA: Ignore DOS end-of-line characters (ctrl-Z) unless -W

[Eli Zaretskii <eliz at is dot elta dot co dot il>]

On Wed, 8 May 2002, Zack Weinberg wrote:

> Perhaps we could make the warning on by default if (a) the system is
> Unix-y, (b) there is other text after the ^Z (besides more ^Z-s).

This sounds good to me.

> > There's no relation between ^Z and newlines whatsoever.  Old DOS
> > editors could put a ^Z anywhere, including several ^Zs one after
> > another.
> 
> Do they ever insert a ^Z in the middle of a file in order to truncate
> it, and not bother to update the filesystem's idea of the file size?

Yes, that can happen, although not very frequently.

> (This is the only way I can think of that there would be a ^Z with a
> bunch of text after it, when the file is transferred to a system that
> ignores ^Z.)

There's another way: take a file with a trailing ^Z, then edit it with an 
editor which doesn't throw away ^Z, and add some text after ^Z.  Rare, 
but possible.

> Oh, I get it: on a terminal, "binary mode" is what Unix calls "raw
> mode".

Yes, exactly.  Switching the terminal to binary mode with setmode also 
switches the terminal device to raw mode.  (Since there's a single 
terminal device, that has a side effect of switching stdout to raw mode 
as well, which is another reason not to do that.)

> Yeah, we should not set binary mode on terminals under DOS.  Do
> you think we should worry about that for anything other than standard
> input (e.g. "cpp con:")

Just use isatty on the file handle, it will DTRT.  Normally, standard 
input is the only handle you should worry about, but things might get 
tricky under a debugger, for instance.  Also note that with DJGPP, you 
can say "cpp /dev/tty" and get what you expect.

Binary input from a terminal doesn't make sense anyway: you don't expect 
a user to type non-printable characters from the keyboard, except ^Z and 
such likes, where you actually _want_ their special effects to take place.

> > Either O_TEXT in `open' or "rt" in `fopen'.  (I hope I understood the
> > question, since I think you already know that.)
> 
> That's what I was asking.  There isn't any such thing as O_TEXT in
> Unix land, you see.

Well, the usual trick is to do

#ifndef O_TEXT
# define O_TEXT 0
#endif

in some header file where such portability issues are dealt with.

> I would like to get patches that made cppfiles.c use whatever
> interface is closest to the bare metal on all supported operating
> systems.

Yes, I agree that such ugliness should be pushed as low as possible.