This is the mail archive of the cygwin@sourceware.cygnus.com mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: ASCII and BINARY files. Why?


Alex Stewart wrote:
> 
> > : The issue of modes on pipes would be much less of a problem if the :
> > mechanism for converting between DOS/Win text and C native : text were a
> > 1:1 mapping (i.e. NL->CRLF, CRLF->NL, CR->CR(always), : (and LF->NL, but
> > that's a side-issue)).  This way, if I want to pipe : "gzip -dc file |
> > tar xvf -" (as I often do), it wouldn't matter what mode : the pipe was
> > created in as  long as it was the same mode on both ends, : because any
> > changes introduced in a C->text conversion would be exactly : reversed in
> > the text->C conversion on the other end of the pipe.
> >
> > Sounds good.
> > But how do you define LF vs. NL? I consider them to be the same.
> 
> Easy.  LF is when it's in a file, NL is when it's in a C string.  All I
> meant by LF->NL was that if there was a LF character (without a
> preceeding CR) in a file, it would be "converted" (passed through) to a
> NL (LF) when read in text mode. (which actually doesn't have a lot to do
> with the issue 1:1 conversion issue as the writing scheme would never
> produce a raw LF on its own anyway, so it would just make reading
> non-text files in text mode a little cleaner.)

It is worth noting that your 1:1 mapping would require CRNL to be turned
into CRCRLF in order to map it back into CRNL on the other side.
This isn't necessarily bad, as long as programs don't read files in
binary and then write them in text mode.

The easiest way to handle pipes, though, is to always open them
in binary on both ends.  On those rare occasions of reading from or
writing to a Windows program via a pipe, a filter can be inserted
to convert to/from CRLF mode.

> > I often use "tar cvvf - . | gzip > file".
> 
> Which, of course, would still experience problems from the ">"
> redirection, tho such problems would be avoided entirely if my other
> suggestion were implemented and tar and gzip were compiled with a "binary"
> flag which caused them both to set their stdin and stdout to binary mode
> when they started up (as part of crt0 processing or some such).

The sad thing is that the tailor.h file in gzip has a SET_BINARY_MODE
macro that is set to something reasonable for every system other
than cygwin.  For some reason known only to himself, when Geoff Noer
edited that file back in June to prevent the ifdef WIN32 stuff
from being included in the cygwin build (which is no longer relevant
since cygwin gcc no longer defines WIN32), he didn't take the extra
two seconds to add the right line for cygwin.   Just add

#ifdef __CYGWIN32__
#  define SET_BINARY_MODE(fd) setmode(fd, O_BINARY)
#endif

to that file and rebuild.

--
<J Q B>
-
For help on using this list, send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]