Thanks for the careful discussion. It almost all makes sense to me.
> > 1) In the Cygwin User's Guide, page 33:
> >
> > c. Pipes and non-file devices are opened in binary mode, except if
> > the CYGWIN environment variable contains nobinmode.
> >
> > Warning!
> > In b20.1 of 12/98, a file will be opened in binary mode if any
> > of the following conditions hold:
>
> This documentation is rather old, so it must be read with a grain of salt.
>
> > 1. binary mode is specified in the open call
> > 2. the filename is a MS-DOS filename
> > 3. the file resides on a binary mounted partition
> > 4. CYGWIN contains binmode
>
> In particular, CYGWIN defaults to binmode, but binmode/nobinmode only affects
> non-disk files (ie. pipes, special devices) - it has no bearing on disk
> files,
> since that is what mount is for.
>
> > 5. the file is not a disk file
>
> In other words, 4 and 5 should be merged into a single condition.
As you've surmised, the part I'm stumbling over is Warning number 4.
The overall intention of the set of warnings seems clear, that any one
of the conditions will give rise to binary mode files. My reading of
4 is thus: "a file will be opened in binary mode if .. CYGWIN contains
binmode". My interpretation is thus that when a shell is redirecting
to a file it will open the in binary mode (because I have
CYGWIN=binmode). Hence my expectation that dd's stdout would be in
binmode in the context of popen("gzip|dd>file","w"), and, originally,
that gzip's stdout would be binmode in popen("gzip>file","w").
It seems to me that if the shell(s) were to honor Warning 4 when
redirecting, then maintainers of individual programs would not have to
fuss over whether to change the modes of the stdin/stdout fds that
they've been given. This puts (or leaves) control in the hands of the
caller of the executable. And this supports a desireable uniformity
of behavior. OTOH, this would appear to require that every use of
fopen() or open() should worry about the value of CYGWIN.
Your suggestion of merging warnings 4 and 5 appears to be an attempt
to change the documentation to match the current implementation. What
would a merged 4 and 5 be saying that isn't already covered by what
(c) itself is saying? Could 4 and 5 be removed? This then puts the
onus on each implementor to decide what to do with their stdin/stdout
fds. This would lead to less uniformity of behavior. It might lead
to finer control in the form of a proliferation of [io]flag= options,
but there would very likely be less consistency. A benefit might be
that CYGWIN=binmode goes away as having any meaning, and only
CYGWIN=nobinmode matters.
In either case, the documentation should be reworded, and that is
something that I'd be willing to help with (once I understand more
about the intent and/or practices associated with
CYGWIN=[no]binmode).
-Hugh
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
