From: Dirk Fieldhouse <fieldhouse@gmx.net>
To: DASH mailing list <dash@vger.kernel.org>
Cc: Harald van Dijk <harald@gigawatt.nl>
Subject: Re: 'return' from subshell in function doesn't
Date: Mon, 9 Mar 2020 12:43:28 +0000 [thread overview]
Message-ID: <320e79a9-0c93-8070-451b-ddc3b50b195e@gmx.net> (raw)
In-Reply-To: <71fc6831-8193-e977-3437-6181dc79842b@gigawatt.nl>
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
prev parent reply other threads:[~2020-03-09 12:43 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <S1726267AbgCHLof/20200308114435Z+1505@vger.kernel.org>
2020-03-08 12:35 ` 'return' from subshell in function doesn't Dirk Fieldhouse
2020-03-08 13:44 ` Harald van Dijk
2020-03-08 14:40 ` Dirk Fieldhouse
2020-03-08 15:19 ` Harald van Dijk
2020-03-09 7:44 ` Stephane Chazelas
2020-03-09 12:43 ` Dirk Fieldhouse [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=320e79a9-0c93-8070-451b-ddc3b50b195e@gmx.net \
--to=fieldhouse@gmx.net \
--cc=dash@vger.kernel.org \
--cc=harald@gigawatt.nl \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).