On 11/03/20 14:03, Chet Ramey wrote:
>...>
> So what's the goal here? That the function continue execution in the
> subshell so `return' has consistent, if baffling, semantics? That we
> tighten up the language to make the unspecified specific? What is this
> discussion intended to accomplish?
I refer you to this excerpt:
> On 3/11/20 9:12 AM, Dirk Fieldhouse wrote:>...>
>> a) the wording of the standard about 'return' doesn't say this (or
>> as you said,
>>> what [I] believe it appears to say, and what it
>>> actually means, are probably not the same thing.
>> which is not a good look for a standard);
>...>
If the standard can easily be misinterpreted, it ought to be reworded.
The interesting discussion prompted by my original post indicates that
even experts don't agree on the interpretation of the text that
specifies 'return'.
Did the wise authors of that text mean 'return' to cause:
i) a return from the function's lexical scope, subject to some missing
definition of that scope, or
ii) a return from the execution environment of the function's defining
command, or otherwise like 'exit', or
iii) a return from the execution environment of the function's defining
command, or otherwise unspecified?
Perhaps the answer is (i) but owing to existing practice the standard
should say (ii) or (iii).
As to "baffling semantics", I suggest that these are two examples where
'return' is meaningful (and far from baffling) and that "foo" and not
"bar" should be printed in each case:
f1() {
( echo foo; return )
echo bar
}
and
f2() {
echo foo |
if read -r xx && [ "$xx" = foo ]; then
echo "$xx"; return
else
echo "$xx"
fi
echo bar
}
Without committing to the usefulness of any example, in a usage like
f1() the author might want to use some variables without overwriting them.
/df
--
London SW6
UK
