This is the mail archive of the cygwin 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]
Other format: [Raw text]

Re: bug with built-in commands in bash when redirecting output


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/


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