This is the mail archive of the cygwin-apps@cygwin.com 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: gbs cleanup patch, 2nd try


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


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