Mail Archives: cygwin/1996/10/29/15:36:35
DJ Delorie wrote:
>
>
> > Many UNIX programs don't specify WHAT??? O_BINARY is strictly a
> > MS-DOS artifact. Well, maybe Mac's have it, I don't know. There
> > _is_ no O_BINARY flag in UNIX, so I would hazard to guess that there
> > are _very_ few UNIX programs that use it.
>
> It's easy to add to the beginning of a unix program:
>
> #ifndef O_BINARY
> #define O_BINARY 0
> #endif
Non sequitur. No one said it wasn't.
> > I would suggest that for maximum compatibility files should default
> > to binary mode.
>
> We've had this discussion on the djgpp group many times. For some
> programs, it makes sense, but we almost always end up adding a
> command-line option to change the default.
>
> If cat were binary, and you cat'd two files with ^Z in them, when you
> read the file with another program, it stops at the first ^Z and you
> don't see the second file at all.
Not if the second program defaulted to binary. (And if the second program is
a DOS program, you can't even count on what it will do with CR-less NLs.)
I would like to see an environment variable that would force the library into
binary mode. That would make it always *possible* to get binary behavior
(i.e., work like unix), even for programs not modified to provided it. This
would work well for those of us who primarily use unix tools only on unix
files, and for programs that treat both NL and CRNL and eol themselves rather
than counting on getc to do it for them.
Maybe we can file a class action suit for a few billion against the turkey who
unleashed on the world a system with such fundamentally bad design decisions
as a two-character EOL indicator and an in-band EOF indicator.
--
<J Q B>
-
For help on using this list, send a message to
"gnu-win32-request AT cygnus DOT com" with one line of text: "help".
- Raw text -