forks/apenwarr-redo
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
apenwarr-redo/t/000-set-minus-e/all.do

4 lines
80 B
Text
Raw Normal View History

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).
2012-02-08 23:59:46 -05:00
rm -f log
Avoid bashism >&file The >& form is only for file descriptors, passing a file name there is a bash extension. $ /bin/dash -c 'echo foo >&/dev/null' /bin/dash: 1: Syntax error: Bad fd number
2015-08-27 06:57:27 -07:00
redo fatal >/dev/null 2>&1 || true
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).
2012-02-08 23:59:46 -05:00
[ "$(cat log)" = "ok" ] || exit 5
Reference in a new issue Copy permalink