X-Spam-Check-By: sourceware.org
To: cygwin AT cygwin DOT com
From: Eric Blake <ebb9 AT byu DOT net>
Subject:  Re: bug with built-in commands in bash when redirecting output
Date: Tue, 23 Jan 2007 19:00:09 +0000 (UTC)
Lines: 45
Message-ID:  <loom.20070123T193447-734@post.gmane.org>
References:  <45B638BE DOT 80003 AT acm DOT org>
Mime-Version:  1.0
Content-Type:  text/plain; charset=us-ascii
Content-Transfer-Encoding:  7bit
User-Agent: Loom/3.14 (http://gmane.org/)
X-IsSubscribed: yes
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id: <cygwin.cygwin.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

Sjoerd Mullender <sjoerd <at> acm.org> writes:

> 
> The following one liner illustrates a bug in sh:
> $ /bin/bash -c '/bin/bash -cx '\''x=`echo hello`'\''' >  <at> x
> ++ echo hello
> + x=$'hello\r'
> $

Odd.  But reproducible - thanks for the test case.  Even though the cygwin 
documentation states that the pipe created for `` should default to binary mode 
(unless you messed with $CYGWIN), you are indeed getting a text-mode pipe, due 
to stdout being textmode, but only when using the shell builtin.

> 
> The bug, it seems to me, is that the shell checks that its output is
> redirected to a file and that it therefore has to write \r\n at the end
> of each line.  So far so good.  However, when it executes a built-in
> command within back quotes, it still uses this knowledge and still
> writes \r\n.

Wrong.  Bash never writes \r - it only writes \n, and then relies on cygwin's 
determination of whether stdout is text or binary for whether cygwin will add 
\r.  The problem is that the builtin is getting a command substitution pipe in 
text mode.

I am suspecting a potential cygwin bug in fork().  Using the builtin echo, the 
sequence is that bash creates the pipe, then forks, the forked child sees that 
stdout is text mode, then rearranges fd's around so that the pipe is now 
attached to stdout, all before any output occurs - but by then the damage is 
done, since stdout remains in text mode.  Using /bin/echo is immune, because 
the fork is followed by an exec() that starts from scratch, determines that 
stdout is a pipe, and defaults back to binary mode.

I'll have to do further investigation, to see whether it is really bash's or 
cygwin's fault (so far all I've done is look at straces), and even if it is 
cygwin's fault, whether bash can work around it until a cygwin patch is 
available.

Meanwhile, have you considered using the cygwin-specific igncr shellopt?

-- 
Eric Blake
volunteer cygwin bash maintainer



--
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/