apenwarr-redo/t/000-set-minus-e/all.do

redo-ifchange ../../redo/sh
rm -f log
redo fatal >/dev/null 2>&1 || true

[ "$(cat log)" = "ok" ] || exit 5
shelltest.od: add more "set -e" tests and add a 'skip' return code. Based on the earlier t/000-set-minus-e bug in minimal/do on some shells, let's add some extra tests that reveal the weirdness on those shells. Unfortunately because they are so popular (including bash and zsh), we can't reject them outright for failing this one. While we're here, add a new return code, "skip", which notes that a test has failed but is not important enough to be considered a warning or failure. Previously we just had these commented out, which is not quite obvious enough. ...and I updated a few comments while reviewing some of the older tests. 2018-12-17 12:35:32 +00:00			`redo-ifchange ../../redo/sh`
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`