minimal/do: fix a really scary bugs in "set -e" behaviour.

If you run something like

  blah_function || return 1

then everything even *inside* blah_function is *not* subject to the "set -e"
that would otherwise be in effect.  That's true even for ". subfile" inside
blah_function - which is exactly how minimal/do runs .do files.

Instead, rewrite it as

  blah_function
  [ "$?" = "0" ] || return 1

And add a bit to the unit tests to ensure that "set -e" behaviour is enabled
in .do files as we expect, and crash loudly otherwise.

(This weird behaviour may only happen in some shells and not others.)

Also, we had a "helpful" alias of redo() defined at the bottom of the file.
Combined with the way we use '.' to source the .do files, this would make it
not start a new shell just to run a recursive 'redo' command.  It almost
works, but this stupid "set -e" bug could cause a nested .do file to not
honour "set -e" if someone ran "redo foo || exit 1" from inside a .do
script.  The performance optimization is clearly not worth it here, so
rename it to _redo(); that causes it to actually re-exec the redo program
(which is a symlink to minimal/do).
This commit is contained in:
Avery Pennarun 2012-02-08 23:59:46 -05:00
commit c28181e26f
6 changed files with 24 additions and 4 deletions

1
t/000-set-minus-e/.gitignore vendored Normal file
View file

@ -0,0 +1 @@
log

4
t/000-set-minus-e/all.do Normal file
View file

@ -0,0 +1,4 @@
rm -f log
redo fatal >&/dev/null || true
[ "$(cat log)" = "ok" ] || exit 5

View file

@ -0,0 +1 @@
rm -f log *~ .*~

View file

@ -0,0 +1,4 @@
rm -f log
echo ok >>log
this-should-cause-a-fatal-error
echo fail >>log # this line should never run

View file

@ -1,3 +1,11 @@
# tests that "set -e" works (.do scripts always run with -e set by default)
rm -f 000-set-minus-e/log
redo 000-set-minus-e/all
if [ "$(cat 000-set-minus-e/log)" != "ok" ]; then
echo "FATAL! .do file not run with 'set -e' in effect!" >&2
exit 5
fi
# builds 1xx*/all
/bin/ls 1[0-9][0-9]*/all.do |
sed 's/\.do$//' |