Date: Wed, 01 Jul 2020 00:43:14 +0300
From: Dmitry Alexandrov <d...@gnui.org>
Message-ID: <tuysgrgt....@gnui.org>
| > If you need to ensure a disk executable is used,
| Of course. Why "command" otherwise?
That doesn't actually work, "command" can run built-ins, there is
actually no method (not even via use of "env") which guarantees
execution of an executable from an external file, other than by
using the complete path name (containing at least one '/') of the
desired file.
command avoids executing functions. That's its purpose (so you
can write
cd() {
test "$1" = "-b" && set -- whatever
command cd "$@"
}
(probably not quite that) without getting recursive "cd' invocation.
It also changes the rules for what happens with errors encountered
with special builtins (but unless in posix mode, bash tends to ignore
those anyway).
When given no options (just args) or with just -p (and args), there's no
reason at all for "command" to ever invoke a subshell for itself, all it
does is alter the search strategy for the command name that follows.
I'd actually call bash's behaviour a bug, and if not strictly that,
then certainly "extraordinarily non-intuitive" - rather than just an
"untaken (yet) opportunity for optimisation".
kre
