return is a special built-in utility, and it should only be used on functions and scripts executed by the dot utility. That's what the POSIX:2001 specification requires.
If you return from any other scope, for example by accidentally calling it from a script that was not sourced but executed directly, the bash shell won't forgive you: it does not abort the execution of commands. This can lead to undesired behaviour.
A wide variety of shell interpreters silently handle such calls to return as if exit had been called.
An easy way to avoid such undesired behaviours is to follow the best practice of setting the e option, i.e.
set -e. With that option set at the moment of calling return outside of the allowed scopes, bash will abort the execution, as desired.
The POSIX specification does not guarantee the above behaviour either as the result in such cases is "unspecified", however.
'set -e' may be useful as hardening flag, but cannot replace error handling.
ReplyDeleteFor example 'f() { set -e; echo "a"; false; echo "b"; }; (f || echo "c")' does not do what most people would expect.
I really tried understanding your example, but I couldn't. Why doesn't the false command fail in this case (both in bash and dash)? Or is it a bug?
DeleteI asked about this some time ago on http://stackoverflow.com/questions/6930295/set-e-and-short-tests and the answer was:
When this option (set -e) is on, if a simple command fails for any of the reasons listed in Consequences of Shell Errors or returns an exit status value >0, and is not part of the compound list following a while, until, or if keyword, and is not a part of an AND or OR list, and is not a pipeline preceded by the ! reserved word, then the shell shall immediately exit.