This is the mail archive of the
mailing list for the Cygwin project.
Re: bug with built-in commands in bash when redirecting output
- From: Eric Blake <ebb9 at byu dot net>
- To: cygwin at cygwin dot com
- Date: Tue, 23 Jan 2007 19:00:09 +0000 (UTC)
- Subject: Re: bug with built-in commands in bash when redirecting output
- References: <45B638BE.email@example.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
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
Meanwhile, have you considered using the cygwin-specific igncr shellopt?
volunteer cygwin bash maintainer
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html