Bash sometimes writes to stdout in MS_DOS format.

Andy Hall A.Hall@servicepower.com
Wed Mar 11 03:14:00 GMT 2009


I am having a very strange problem with bash 3.2.48-21 It goes like
this.

From a bash shell I invoke another bash shell as follows: 

	ERROR_LOG="/tmp/error.$$.log"
	BUILD_LOG="/tmp/build.$$.log"
	...
	./$PRODUCT_CMD"  >"$BUILD_LOG" 2>"$ERROR_LOG"

All my files are mounted in binmode E.g.

	C:\cygwin\bin on /usr/bin type system (binmode)
	C:\cygwin\lib on /usr/lib type system (binmode)
	C:\cygwin on / type system (binmode)
	c: on /cygdrive/c type system (binmode,noumount)
	d: on /cygdrive/d type system (binmode,noumount)

If $PRODUCT_CMD encounters an error, it will execute the following
function to write an error message to stderr and stdout and exit with a
specified non-zero exit code. 

errmsg () {
        # Error information is written to the stderr in the
        # form of parameter settings that can be read by a
        # parent shell
        echo "BUILD_MASTER=\"$BUILD_MASTER\"" 1>&2
        echo "PRODUCT_ENGINEERS=\"$PRODUCT_ENGINEERS\"" 1>&2
        echo "ERROR_MESSAGE=\"$1\"" 1>&2
        # Log message to stdout as well.
        [ "$1" != "" ] && echo "$1"
        [ "$2" != "" ] && exit $2
}

The parent command on getting a non-zero exit code.  Does the following.

	. "$ERROR_LOG"

Now here is the strange stuff.

1.  If I start the parent script from a bash window, this all works
fine. If the child script exits with a non-zero exit code, the "."
command reads the $ERROR_LOG without a problem. 
2.  If the parent script is started by a Windows task running as the
cygwin user, the $ERROR_LOG will SOMETIMES be written in DOS format with
CR LF line endings.  It seems to depend on the depth of function nesting
at the time errmsg is invoked.  It is as if bash "forgets" some
attribute of file descriptor 2 under some curious circumstances.  This
is totally repeatable.  All I have to do is induce certain errors
detectable by the child script, $PROGRAM_CMD.

I have been unable to create a simple test case that exhibits this
behavior, probably because of #1. 

The scripts are pretty much platform independent and run on Linux,
Solaris and HP-UX without a problem.  There are only a few things which
are platform dependent. I can of course inject a work-around if the
script is running in the cygwin environment.  I am wondering if anybody
has any plausible explanation for this.  

Andy Hall


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



More information about the Cygwin mailing list