On 14/03/20 01:26, Robert Elz wrote:
Date: Fri, 13 Mar 2020 16:49:14 +0000
From: Dirk Fieldhouse <fieldho...@gmx.net>
Message-ID: <ced1a4b8-2f25-3a3b-db32-5a9326cb8...@gmx.net>
| But as 'return' is behaving like 'exit', and not actually returning (ie,
| setting $?=7 in the invoking shell and not printing no or 7) in this
| case, might it not be better to leave such usage for a commentary in
| non-normative text?
The standard says what the shells do, and what scripts can rely upon.
That is what this is.
The fact that a behaviour exists in a wide range of implementations, in
a context held by many experts to be unspecified by the current
standard, doesn't mean that scripts should be able to rely upon it. If a
script relying on that behaviour works now, it's only through
suck-it-and-see programming; far be it from me to say that it deserves
to break, or indeed to promote a POSIX-conformant shell implementation
that fails an attempted 'return' from a subshell.
When the name 'return' was introduced into the shell it was already a
well understood programming concept used by that name in many languages.
Owing to the execution model of the shell, that concept couldn't be
implemented in the shell without constraints that were never clearly
documented, but must have been well known to implementers.
Since the constraints needed for 'return' to do so have not been widely
understood (eg
<https://www.dartmouth.edu/~rc/classes/ksh/functions.html>), there is
obvious benefit in standardising them, but since the 'exit'-like
behaviour could never previously have been relied upon standardising it
would just muddy the concept implied by the name 'return'. You say later:
> ... we document what works, not what we think is "better".
Documenting, fine. Standardising, perhaps not so much?
| If 'return' doesn't return from general subshell contexts,
Return in sh is *never* going to return the way you want it to. Never.
You're reading too much into "If". I think it's clear that design
decisions from several decades ago take precedence, regardless of what
anyone would prefer. Eg
<https://minnie.tuhs.org/cgi-bin/utree.pl?file=Ultrix-3.1/src/cmd/sh5/xec.c>
where apparently the case of "not in a function" is handled and
otherwise a (per-process) flag is set so that nothing else is executed
until the next function call is unwound, or the process exits, whichever
comes first.
| shell programmers have to live with work-arounds like
|
| f() { (exit 7; echo no); return; }
|
| instead of
|
| f() { (return 7; echo no); }
Those two achieve the same thing, in a slightly different way. ...
Is there any suggestion that the 'exit'-like behaviour of any shell that
implements it for 'return' in such contexts is subtly different from 'exit'?
... there are times when things need to be written carefully to achieve
particular effects (the same when one wants to save side-effect results
from a pipeline - "return" isn't the only thing that gets affected by the
way subshells (that is, separate execution environments) work in the shell.
Indeed, but the issue of variable scope in a pipeline seems to be more
widely understood, eg <https://github.com/koalaman/shellcheck/wiki/SC2031>.
And once again, if you don't like the way the shell language works, go
and invent a new one, then implement and distribute it.
...
I'm certainly not angling for that.
There are plenty of (whisper it, and without attaching any blame -- not
like this guy
<http://www.softpanorama.org/People/Shell_giants/introduction.shtml>)
better designed scripting languages around, but not ones that you can
expect to see installed by default on a POSIX-conformant environment and
even raise defect reports against if they don't do what POSIX specifies.
And if the standard lays down when 'return' returns and when it might do
something else, that's potentially a validation case for shellcheck.net.
/df
--
London SW6
UK
