err_return inside function who's return value is checked

err_return inside function who's return value is checked

[Russell Harmon]

why does the following print hello?

(){ setopt err_return; false; echo hello } || :

is this a bug?

--
Russell Harmon

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

[Bart Schaefer]

On Dec 30,  2:52am, Russell Harmon wrote:
}
} why does the following print hello?
} 
} (){ setopt err_return; false; echo hello } || :
} 
} is this a bug?

It seems to be in the realm of what might be called unreliable behavior.
Compare bash 3.2, for example:

bash-3.2$ foo() { set -e; false; echo hello; }
bash-3.2$ foo || echo goodbye
hello
bash-3.2$ foo && echo goodbye
hello
goodbye
bash-3.2$ foo
[exits]

err_return is supposed to act just like err_exit, and err_exit does not
cause the shell to exit when used in a conditional expression, and so
err_return does not cause the function to return in that circumstance.

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.

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

[Russell Harmon]

On Sun, Dec 30, 2012 at 2:35 PM, Bart Schaefer
<schaefer@brasslantern.com> 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? It would enable idioms like the following to be used:

function get_major_version {
  setopt err_return
  [[ $(program -V) =~ "version ([[:digit:]]+)\." ]]
  REPLY=$match[1]
}

which I think is quite nice

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

[Bart Schaefer]

On Dec 30,  3:55pm, Russell Harmon wrote:
}
} On Sun, Dec 30, 2012 at 2:35 PM, Bart Schaefer
} <schaefer@brasslantern.com> 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.)