Joerg Schilling via austin-group-l at The Open Group dixit:
>OK, mksh pdksh and posh have te same origin.
>I don't know oksh, loksh
oksh is basically where mksh took off, an intermediate, pdksh without
its compatibility layer and with a small amount of bugfixes; loksh is
a GNU/Linux port of oksh.
>The POSIX text is:
>
> If exec is specified with command, it shall replace the shell
> with command without creating a new process. ...
>
>So the main statement in both is that the command is executed in place of
I even referred to that as well, but as I read POSIX it defines
what “command” is to include functions.
Robert Elz via austin-group-l at The Open Group dixit:
>This has been discussed (somewhere) before - but in the context of being
>able to guarantee that the filesystem command is run, and not anything
>else. Specifying the full path will do that, but to do that portably
>means the script needs to do its own PATH search, and that's ugly.
OK, that is tricky to do _portably_…
>The overall conclusion is that
> (exec command)
>is the best way to do it. That requires that exec only ever run filesystem
>commands, which is what it did historically.
Yes, historically, but not universally.
>The standard is simply poorly written (I guess that no-one ever
>imagined anyone being dumb enough to do it differently).
Eh, doing it differently is pretty much what I’d *expect* as user.
I expect that prefixing exec does not change what is actually run.
That being said, the Korn shells have a way to do PATH search, so
"$(whence -p commandname)" args…
implements the problem from above.
>My memory is that this is to be fixed in the next version.
Oh? I’d like to read about this if it’s normative.
(But that’d just mean the current implementation in mksh, where
the legacy ksh88-style way of exec is used if set -o posix is
set, can stay as-is.)
>Note that the sometimes suggested "env command" isn't guaranteed to work,
>env just sets up the environment, for the command, then runs it. There's
>no reason that env cannot be built into a shell, and if it is, then being
>able to run finctions and builtin commands (particularly with env -i) is
>a very useful ability to have.
AND HOW DOES *THAT* DIFFER FROM exec?
In fact, *env* is the one I’d expect to always run the external
binaries… after all, env can be used to set up the environment in
ways the shell rightfully refuses, and for this it’ll need to run
through an env-changing exec* variant syscall.
By contrast, prepending “exec” in the shell merely makes it so that
the shell afterwards doesn’t continue, where possible optimising it
as exec syscall. (But GNU bash, of course, cannot even get THAT right.)
Interestingly enough, the env documentation speaks of “utility”, not
“command”. I *think* this excludes functions, although it specifically
mentions special built-ins aren’t supported.
Is there any implementation of env that can call functions (and/or
builtins) around? Otherwise I’d argue in favour of making sure that
env can be used to get the external executable always, and allowing
shells to use either for exec. (This is also more right because exec
must always be a builtin, while env is not normally one.)
I always thought the only difficulty in env is that it’s not available
everywhere (e.g. older OpenBSD releases) and that some systems don’t
have it in /usr/bin/ so shebangs are problematic.
bye,
//mirabilos
--
22:20⎜<asarch> The crazy that persists in his craziness becomes a master
22:21⎜<asarch> And the distance between the craziness and geniality is
only measured by the success 18:35⎜<asarch> "Psychotics are consistently
inconsistent. The essence of sanity is to be inconsistently inconsistent
