Re: err_return inside function who's return value is checked

[Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>]

On Dec 30,  3:55pm, Russell Harmon wrote:
}
} On Sun, Dec 30, 2012 at 2:35 PM, Bart Schaefer
} <schaefer@xxxxxxxxxxxxxxxx> wrote:
} > This obviously is a case where err_return might be permitted to behave
} > differently without causing too much consternation, but that's not how
} > it has been defined.
} 
} Can this be arranged?

Anything's possible. :-)  I'm not personally very familiar with this part
of the internals, so I'm not sure how difficult it would be.  However ...

} It would enable idioms like the following to be used:
} 
} function get_major_version {
}   setopt err_return
}   [[ $(program -V) =~ "version ([[:digit:]]+)\." ]]
}   REPLY=$match[1]
} }

This isn't really what err_return (or err_exit) is meant for.  If you
have cases where you are *expecting* the command to fail, you should
be able to write

    [[ $(program -V) =~ "version ([[:digit:]]+)\." ]] || return

just as easily.  Instead, err_return is intended to trap unexpected
failures, or conditions that occur so rarely that it over-complicates
the flow of control to constantly test $? after each command.

E.g., suppose you're calling a function someone else wrote.  Somewhere
in that function is a "chmod" command, which is never expected to fail
(it's return status isn't tested) but if it does fail it'll leave a
security hole in its wake.  So *outside* of that function you setopt
err_return to force it to stop if the chmod does not work.

(Of course the above would lead to the argument that "emulate" should
not mess with err_exit/err_return.)