Robert Elz <k...@munnari.oz.au> wrote, on 18 Jul 2017:
>
> | I think "command" is the right word here. It's talking about a specific
> | usage of "exec" (with no operands) in a command, not about the exec
> utility
> | in general.
>
> What it says is "the exec command" - it is very definitely talking about
> the exec utility.
No; in this context, "the exec command" is a reference to a specific
command in which the command word is "exec". It is not the same thing
as "the exec utility".
> And while I agree that command is a perfectly good English word that
> describes what is intended, I suspect that's what the authors of the
> original exec page would have said of their usage of the word as well.
>
> What harm can be done by being more precise (here, and in the other places) ?
It is not more precise; it is less correct.
I really don't understand why you have a problem with this usage. The
problem with the existing text is that it implies that what *follows*
the word "exec" is a command. Having "exec" be the command word within
the command is a completely different thing.
> | That is just what became of the current first paragraph of the exec
> | description:
> |
> | The exec utility shall open, close, and/or copy file descriptors
> | as specified by any redirections as part of the command.
> |
> | It seemed like this was now covered by other text, except for the case
> | of failure to execute the utility.
>
> Yes, it is the failure case that is of interest. But I suppose a shell can
> avoid this, simply by noting that the (proposed) text says ...
>
> [UP]If the <i>exec</i> command fails and the shell does not exit, any
> redirections associated with the <i>exec</i> command that were
> successfully made shall take effect in the current shell environment.
> [/UP]
>
> and then determining that an error was detected before any redirections
> were performed, hence none "were successfully made" and thus do not need
> to take effect.
>
> The effect on the script is the same as if the text said "may", it means
> that if an exec is attempted, and fails, the script has no idea (without
> testing) whether any redirects were performed, and persist, or not.
>
> Examples of cases where this might be reasonable for the shell to do
> would be
>
> exec '' >/dev/null
> exec . 2>/tmp/foo
> exec / < /dev/tty
>
> In those kinds of examples, it is obvious that the exec cannot possibly
> succeed, there's no need to preform useless execxx() sys calls to
> discover that - though a shell can if it doesn't want to look at the
> arg string that closely). Further it might be reasonable to allow that
> kind of check to be done before processing anything else (like redirects)
> that are on the command line
It would be reasonable to allow that, but the current standard does
not allow it, which is why I had the same requirement in my proposed
new text.
> - and if those tests are permitted, why not
> others as well ("this same exec of this same path has failed 100 times in
> the past second, it is not going to succeed the 101st time...")
That specific example is definitely not okay. Whatever caused the 100
failures could be corrected at that point, and the 101st attempt succeeds.
> Next, since we are onto matters of slightly more substance than my previous
> message, I wonder if we really have to require that the shell only ever
> process things in external files as its argument.
>
> That is, while I would not want to require a shell to implement it, is it
> really necessary to forbid the behaviour that raised this issue in the
> first place?
>
> If I have a shell function foo, why should I not be able to "exec foo"
> to run the function, and then exit, just as I can "exec ls" to run ls,
> and exit in one step? In both cases I could just do "xxx; exit" the
> "exec" is not really necessary, except for perhaps utilities like login
> (and there is no intent here to alter the "replace the shell with the
> utility" behaviour of exec, just how utility is located.)
>
> The purpose of "exec" (with operands, the redirect only case is different)
> is to replace the shell with the utility named, so that when the utility
> completes, the current process terminates. I cannot see a good reason that
> should not apply to built-in utilities (even specials, though "exec break"
> would be a little weird) and functions.
I don't really have an opinion on this. So far all I have done is
asserted what the original POSIX.2 developers intended to require (the
ksh88 behaviour) and proposed wording changes which specify that behaviour.
> The task of modifying where the shell searches to find a utility seems to
> be something better suited to the "command" utility, which is designed for
> that purpose.
Is there any existing practice of extending "command" to provide this
feature?
--
Geoff Clare <g.cl...@opengroup.org>
The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England
