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. >
