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