Date: Sat, 14 Mar 2020 22:43:05 +0000
From: Dirk Fieldhouse <fieldho...@gmx.net>
Message-ID: <06785188-5da9-1494-2af3-4456759cb...@gmx.net>
| 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.
No it doesn't, but it is a candidate for the standard to switch from
being unspecified to defining the hehaviour, given that all the shells
implement it anyway - after which scripts can rely upon it. That's how
the standard evolves.
| > ... we document what works, not what we think is "better".
|
| Documenting, fine. Standardising, perhaps not so much?
I was referring to "in the standard". The standard is not static,
things are added (or move from unspecified to specified) as the
implementations converge upon some common definition for something new
or previously unspecified, and things are deleted when they become
obsolete, and are implemented only to satisfy the standard, or move
to being unspecified when it is clear that despite the standard there
is in fact no common definition. Of course all of this happens at
a glacial pace.
| 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'?
Not that I am aware of. exit is kind of blunt, it is quite hard to
be subtly different - I suppose the one difference might be whether the
EXIT trap (if there is one) is run, but (without testing yet) my guess
is that it would be (whether the subshell exits because of a return, an
explicit exit, or just by falling off the end should make no difference
to exit trap processing).
Actually, I have just tested it ... bosh and yash do not run the EXIT
trap when a subshell (with a trap in it .. the test is shown below)
exits because of a "return" command in the subshell. All other shells
I have to test against do. When "return" is changed to "exit" all shells
run the exit trap, as they do when the statement is omitted comletely
(in which case the following echo obviously runs, and the exit status from
the subshell is 0).
The test is:
$SHELL -c 'f() { (trap "echo FOO" EXIT; return 5; echo BAR); echo "$?"; }; f'
The shells that behave properly (all of them when "return" is replaced
by "exit") print FOO, and then 5, bosh and yash simply print 5 for this case.
kre
ps: one "interesting" thing from this, is that when that was run in the
shells interactively, rather than via "$SHELL -c" all acted the same way
when "return" was used (the same way as reported above for each of them)
but when "exit" is used (ie: in the case where the trap is actually run)
bosh caused the subshell to stop (SIGTTOU) - foregrounding it simply makes
causes it to stop again - that is, for some reason, when interactive (ie:
with set -m) bosh seems to be running that subshell in a different process
group (which is correct) but not changing the terminal to be in that pg.
That's a bug (since it is a foreground process).
bosh $ echo ${.sh.version}
version bosh 2020/01/24 a+ (amd64-unknown-netbsd8.99.30)
It came from schily-2020-02-11.tar.bz2
Even more weird, when the "exit 5;" is simply omitted, that doesn't
happen, bosh prints BAR FOO 0 (on 3 lines of course) as it should, without
anything stopping - which indicates that in this case, either it runs the
subshell in the same process group as the parent (unlikely) or switches the
terminal to the process group of the subsjell (more likely) which it doesn't
do when the exit command is present (either explicitly, or "hidden" using
X=exit and then using $X instead of "exit" in the function).
That's simply bizarre.
