X-Spam-Check-By: sourceware.org
Date: Wed, 25 Jul 2007 13:38:00 -0400
Message-Id: <200707251738.l6PHc0j7012306@linode.hodain.net>
To: cygwin AT cygwin DOT com
In-reply-to: <loom.20070725T163755-841@post.gmane.org> (message from Eric 	Blake on Wed, 25 Jul 2007 15:28:55 +0000 (UTC))
Subject: Re: 1.5.24: incorrect default behavior of dd in popen context on  text-mounted filesystem
From: Hugh Secker-Walker <hsw AT hodain DOT net>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 7bit
References: <200707241548 DOT l6OFmXAE008571 AT linode DOT hodain DOT net> <46A64F0F DOT 20706 AT byu DOT net> <200707251419 DOT l6PEJnYK011631 AT linode DOT hodain DOT net> <loom DOT 20070725T163755-841 AT post DOT gmane DOT org>
X-IsSubscribed: yes
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Precedence: bulk
List-Id: <cygwin.cygwin.com>
List-Unsubscribe: <mailto:cygwin-unsubscribe-archive-cygwin=delorie DOT com AT cygwin DOT com>
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com

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/