Date: Tue, 21 Jan 2020 11:34:08 +0000
From: Geoff Clare <g...@opengroup.org>
Message-ID: <20200121113408.GA27285@lt2.masqnet>
| If we do add something, then I think that some non-normative words along
| the lines of your explanation at the bottom ("to clarify that ...")
| would be more helpful than the type of normative addition you are
| requesting.
Something just to make it clear would be better than nothing.
| This phrase is in the existing text (after bug 1150 was applied).
That I didn't know, which is one more reason it would be really useful
to have a current version of the draft available - but that's beside the
point here.
| It's in a small-font note, which means it is non-normative,
but the new proposed text is not
| so I don't see a problem with using this informal phrase to refer
| to the var=... command.
In general terms nor would I (it isn't a command, in the strict sense,
but we might ignore that)
| It's just being used as shorthand for "the command containing the
| assignment to var".
Not really, any other command containing an assignment to a var, which
contained a command substitution wouldn't be relevant, only a simple
command with no command word.
The bigger problem is that the wording suggests there is something
special about command substitutions in assignment statements, which
isn't correct, any command substitution in any command without a
command word works, another is
<<FOO
$(exit 1)
FOO
| The reason for the note is because the existing text (from 1150) says $? is
| the "exit status of the most recent pipeline (see ...) that was not within
| a command substitution".
Yes, I know. And that wording is fine.
| This might cause some readers to think that the exit status of
| var=$(some_command) is not the exit status of some_command, because
| some_command was within a command substitution.
Given your earlier reluctance to add clarifying text, because the standard
is already clear, this is a little surprising. The standard is already
clear about this - the exit status of any simple command which contains no
command word, but does contain a command substitution is the status of that
command substitution (or the last performed, if there is more than one).
A simple command is the degenerative case of a pipeline, so where that
pipeline is a simple command, and that simple command has no command word,
then if there is a command substitution - for which the trivial case is
the command
$(exit 1)
the exit status of that command substitution becomes $? Even though use
in an assignment is the common way this is observed, giving that example
special status would be counter-productive.
If clarifying wording is needed, it should be more like
Note, that when a pipeline consists entirely of a simple command
which contains no command word (xref 2.9.1 .. even better the
appropriate paragraph if there is a way to do that), but which
does contain one or more command substitutions, the exit status
of the last command substitution performed becomes the exit status
of the simple command, and thus of the pipeline, and hence in this
one case determines the value of the special parameter ?.
and it ought to appear in the rationale or something, rather than in the
normative text.
Next issue:
| This behaviour of ksh was the reason I proposed the unspecified behaviour.
Yes, I assumed that.
| The bug, as I see it, is that the value of $? and the behaviour of exit
| differ.
Yes. Or well kind of, the bug is that exit picks the wrong default
for n when executed in a sub-shell where there has been no other command
in the sub-shell which already generated an exit status. That's despite
having a perfectly good exit status from a previous command already
available in $? that could have been used.
| I.e. I think the important thing here is that exit with no argument
| should behave the same as "exit $?".
Yes, it should.
| Given that there is presumably a
| reason that ksh changed the behaviour of exit,
That's a leap. I'd suggest it is far more likely a simple bug
that no-one has previously noticed, as no-one in practice ever
writes
(exit)
as that's 100% pointless. If one wanted a way to generate ?=0
(given that special params cannot be assigned to that way) one would
be far more likely to write : or true or something, than (exit),
especially as in every other shell that is just a slow expensive no-op
(or if sufficiently optimised, a fast meaningless no-op). If there
really was a demand for a sub-shell to do nothing except exit 0, then
one would write (exit 0) as that's going to work everywhere.
| it seems likely that the
| ksh authors will want to fix this bug by changing the value of $? on
| entry to a subshell to match the behaviour of exit.
That's an even bigger stretch. I'd suspect it to be far more likely that
if this was pointed out to them, that they'd simply fix exit, given that its
current behaviour is clearly incorrect, and simultaneously useless.
But regardless of what the ksh93 authors decide to do here (assuming someone
who knows how tells them of this issue - it isn't likely to come up from a
bug report from any normal script) that shouldn't be relevant. Even back
in the days when ksh ruled the standards world (which it should no longer)
straight out bugs in it were not codified (not even as "unspecified".)
kre
