Re: -e does not take effects in subshell

[Ángel González]

On jue, 20-08-2015 a las 17:38 -0700, Linda Walsh wrote:
> Functions are a collection of many commands.  They are not a single,
> simple statement.  I remember using their return value in some cases.
> 
> With the change, I couldn't run a func and have it return the
> value in $? (1 byte, I know) -- but about 128x as flexible 
> as "ok"/"die" (i.e. any non-zero value triggers the behavior
> now, but before, it didn't).
> 
> My simplistic view was that -e was there to auto-exit if an external
> command failed because they are "out of your control".  But if 
> I write a function -- I design the behavior.  Even if I designed in
> a bug -- it's still "my code" that has the problem not some
> -_e_xternal command

If you design the function, you can put an exit 0 on them, so they
never return a non-zero status.
It is completely sensible that if "echo foo > /dev/full" fails, it
behaves the same way no matter if it's /bin/echo or a builtin what is
run by "echo".

Note that Windows has a similar deviation between binaries and batch
scripts.
A .bat containing:
foo
bar

will run foo.exe then bar.exe if there's an executable named foo.exe,
but only foo.bat will be run if it happens to be a .bat script (ie.
acts as if prefixed by exec(1) when it's a .bat). And you can't know
beforehand (even worse, someone may have installed a .bat with the same
name as a .exe in order to slightly augment it).


Treating all of them consistently is the way to go.


> ----  cf. perl's option "autodie" -- you can say you want the "open
> builtin" to just die on errors, then for simple scripts you don't
> have
> to put extra code to handle each problem.  I.e. -- it's not really 
> something you want in production code, but I write far more throw
> away quick and dirty scripts than production ones.  

I would to like to have a way to automatically set -e all functions
defined after that, but it's orthogonal to treating them as commands.

>