Date: Mon, 17 Jul 2017 15:45:08 +0100
From: Geoff Clare <g...@opengroup.org>
Message-ID: <20170717144508.GA18920@lt2.masqnet>
| Robert Elz <k...@munnari.oz.au> wrote, on 17 Jul 2017:
| >
| > Can we forget about irrelevant side issues related to pipelines, etc?
|
| Pipelines are not irrelevant.
I think they are.
| > The issue here is purely where exec looks to find the command
|
| That is the question that was asked, but it has already been answered
I am not 100% certain that really happened. There have been opinions
offered, but until there is actual wording for the standard, it is
not really answered. So let's just answer that.
| The issue now is what changes are needed to the standard.
| Currently the standard says:
|
| If /exec/ is specified with /command/, it shall replace the shell with
| /command/ without creating a new process.
Yes, but I think Chet has provided the correct context for that, just
change "command" to "cmd", in the synopsis, and elsewhere in the exec
description, and that issue goes away.
| When exec is used within a pipeline, this is quite wrong.
Only if you believe that the "command" there is the grammar element
"command" rather than just the word.
| Consider these four commands:
|
| ls | grep foo
| exec ls | grep foo
| ls | exec grep foo
| exec ls | exec grep foo
Just as easily consider
exit 1 | grep foo
(etc).
| Usually in the plain version with no execs, shells call waitpid() for
| the process running grep (since that's the one whose exit status they
| need).
Yes, but how the shell implements it is none of our business.
| In this case, the second command is handled exactly the same
| as the first (i.e. the shell *does* create a new process for ls,
| contrary to what the standard says),
No, the presence of exec, or exit, there is irrelevant, commands (the word,
not the grammar element) in pipelines are permitted to be executed in a
sub-shell environment. That's all that is happening there, whether the
shell forks once, or twice, before running the ls is irrelevant.
| but the third and fourth commands can be different.
Yes, they can.
| It seems that in ksh the grep replaces the shell,
The same with exit | exit
| but in bash it doesn't.
and there as well, again, I think this is all covered by the
"permitted to be executed in a sub-shell" which applies to pipes,
and which is why
echo hello | read var
is not equivalent to
var=hello
(or not guaranteed to be.)
| I'm not sure whether it should guarantee that in the fourth one the
| shell is no longer running after execution of the command (which isn't
| the case for bash, but that is surprising).
No it isn't, it is the same for most shells, ksh is the anomaly here.
kre
