On 08/03/20 15:19, Harald van Dijk wrote:
On 08/03/2020 14:40, Dirk Fieldhouse wrote:
On 08/03/20 13:44, Harald van Dijk wrote:
Subshells work by starting a new process. ...
What the conforming implementation has to do shouldn't be of concern to
the shell programmer, especially since a subshell may, but need not, be
created implicitly in a pipeline; in particular any subshell processes
are transparent to the shell programmer ($! "shall expand to the same
value as that of the current shell").
I think you meant $$ there, but this is the difference between theory
and practice. In theory, the standard is perfect, and shell internals
are irrelevant, we can just look at what the standard says. In practice,
unfortunately, the standard is not perfect and there are numerous cases
where the standard is either ambiguous or contradicts implementations,
and where this is deemed a defect in the standard rather than in the
implementations. It need not even be because what the standard specifies
is unreasonable, it can just be because the what the standard specifies
is unintended.
Yes obvs $$, thanks. If a supplier has to warrant conformance to the
standard they have a problem if what the standard says is universally
ignored. Something has to give. I think it's fair to say that
historically there has been convergence from both directions. But this
particular issue seems to have been a blind spot, perhaps because it
seems so obvious to the implementers who also work on the spec (we've
all been there).
What POSIX says presumably means
that the implementation should wait for any subprocesses, threads or
whatever spawned in the course of executing a function to complete
(subject to &) before continuing to execute the next command. If the
calling script process or some spawned thread of control gets killed
before the return can be executed, that's just an exception, the sort of
thing that traps exist for.
Sure, for the parent process, but for the child process it leaves
questions unanswered such as what the expected output would be of:
f() {
(kill -9 $$; return; echo hello)
}
f
echo bye
If you kill the shell (you're not supposed to know that kill only kills
some main process) you shouldn't expect any subsequent command to have
run. A better name for this f() is cut_off_the_branch_I_am_sitting_on().
I would argue that even if you disagree that the behaviour should be
unspecified in your original example, it should still be unspecified in
mine.
However, as your interpretation seems to have been widely made by shell
implementations, is it necessary to abandon the behaviour currently
specified in favour of a more pragmatic specification?
I suspect so. There is a case I forgot about though:
f() (
return 0
echo bug
)
f
This should not print 'bug', and does not in any shell I can think to
test. By your interpretation of the standard, this is currently
specified. By mine, it would be unspecified, but I would agree that it
should be fine for the whole function to be defined using a () compound
command, and to contain a return statement directly inside it.
+1. Apparently the consensus has been that 'return' in a subshell means
'exit'. But should someone write a test suite with a test case similar
to my original bar() against POSIX.1-2017 these implementations will all
fail to pass.
The same problem applies to the 'break' and 'continue' statements too:
for var in x y z
do
echo $var
(break)
done
As Stephane (instigator of the relevant defect report) pointed out, this
has been addressed in the 2017 text, so that your 'break' example is
unspecified behaviour (unenclosed break or continue). Of course similar
wording could have been used to restrict the specified behaviour of
'return' as well -- but wasn't.
This is looking like a giant can of worms I'm not sure I'm ready to see
opened. :)
Otherwise it would have been sorted out before and I wouldn't have
raised it!
This <https://www.austingroupbugs.net/view.php?id=1042> POSIX DR touches
on the same issue but doesn't come to grips with 'return'.
This <https://www.austingroupbugs.net/view.php?id=1247> DR identifies at
least one other case where an implicit subshell is used.
I suppose further discussion should be at austin-group-l?
regards
/df
--
London SW6
UK
