On 11/03/20 17:32, Don Cragun wrote:
... notice that I said "in the same shell execution environment as the command that invoked
..."; not "in the same shell execution environment as the function's defining
command". If a function is invoked in a subshell of the environment that defined the function
that should not affect the behavior of return as long as the function doesn't doesn't invoke return
in a new shell execution environment
In my "in the same shell execution environment as the function's
defining command ..." please complete the ellipsis with "was invoked". I
think we're saying the same thing.
As function definitions are part of the definition of 'execution
environment', it shouldn't matter where a function was defined.
Your wording seems to cover the cases from 2.12, which are
- command substitution
- subshell compound-group
- asynchronous list
- multi-command pipeline.
But it only goes to unspecified behaviour and there seems to be support
for more specific wording to cover the excluded cases, if only in the
APPLICATION USAGE or RATIONALE sections of 2.14 'return. Leaving that
for the moment ...
Would "using", or "with", be a better term than "running in" in your
proposal? No suitable precedent seems to exist in the current standard
or rationale. Also the two potentially contradictory requirements should
be combined, and there should be a reference out.
As in:
The return utility shall cause the shell to stop executing the
current function or dot script_, if any, and if the shell is _
currently executing _the_ function or dot script _using_ the
same shell execution environment _(see 2.12) _as the command
that invoked the function or dot script_. Otherwise_ the results
are unspecified.
Even with this wording, it isn't clear that there is "the function or
dot script, if any" (ie just one, or none) without first applying the
restriction to the same execution environment, depending on whether you
think that asynchronous commands in a function definition are counted in
the "current function", so this perhaps would be better:
The return utility shall cause the shell to stop executing the
current function or dot script, if any, that is being executed
using the same shell execution environment (see 2.12) as the
command that invoked the function or dot script. Otherwise the
results are unspecified.
APPLICATION USAGE might then point out that 'exit' has defined semantics
in the cases where 'return' has unspecified behaviour, and some
distillation of the issues discussed here might be included in the
RATIONALE or in the RATIONALE for function definition (C.2.9.5).
>...>
/df
--
London SW6
UK
