This is the mail archive of the
cygwin-apps@cygwin.com
mailing list for the Cygwin project.
Re: gbs cleanup patch, 2nd try
- From: Andrew Schulman <andrex at alumni dot utexas dot net>
- To: cygwin-apps at cygwin dot com
- Date: Sat, 30 Oct 2004 14:27:01 -0400
- Subject: 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.