gbs cleanup patch, 2nd try

Andrew Schulman andrex@alumni.utexas.net
Sat Oct 30 18:27:00 GMT 2004


> Sorry, the above is wrong:

Sorry again, but please disregard my previous message.  I was confused 
because I was testing some features of /bin/sh -e on Debian.  On Debian 
/bin/sh invokes bash, while on Cygwin it runs ash.  It turns out that these 
two handle subshells with -e differently:

Cygwin:

$ /bin/sh -e ; echo "finished /bin/sh -e, status=$?"
$ ( false ; echo "continuing" )
finished /bin/sh -e, status=1
$ 

Debian:

$ /bin/sh -e ; echo "finished /bin/sh -e, status=$?"
$ ( false ; echo "continuing" )
$ 

In both cases, the subshell exits as soon as one of its commands returns 
false.  But in Cygwin, the parent shell exits too; in Debian, it doesn't.  
It was the Debian behavior that I reported earlier.  My mistake.

The Cygwin behavior above is consistent with the ash man page.  It also 
means that all of the &&'s in the generic-build-script are definitely not 
needed.  With /bin/sh -e, as soon as any command in a subshell returns 
false, the subshell and parent shell exit.  That's the purpose of the &&'s, 
so they can go.

I tested this behavior by inserting some failing commands into some of the 
gbs functions, and running the script.  With /bin/sh -e at the top, it 
halted at the first false result.

So the patch I posted yesterday is still correct.
Andrew.



More information about the Cygwin-apps mailing list