René Scharfe <l.s.r@xxxxxx> writes:
> What's the significance of "run" and "exec" here? Why do we have both
> variants? Is it to tell apart errors of the actual execve(2) call from
> those in code leading up to it (e.g. when searching the executable in
> $PATH)? But at this point we are after the call, so why is ENOENT
> from execve(2) a "run" thing, not an "exec" thing?
I was reading output from
$ git log --reverse -p -SNOENT 7e5d776854e.. run-command.c
45c0961c (run_command(): handle missing command errors more
gracefully, 2009-01-28) explains how we use NOENT to tell between
"we failed to run the command requested because it did not even
exist" and "we failed to run the command and the reason why it
failed is *not* because it did not exist" (the distinction matters
to implement "run command X on $PATH"). To further that, 38f865c2
(run-command: treat inaccessible directories as ENOENT, 2012-03-30)
and a7855083 (sane_execvp(): ignore non-directory on $PATH,
2012-07-31) dealt corner cases where entries on $PATH were
unreadable or were non-directories, but the idea should be the same.
All of the above matters purely when we fail silently (because we
expect only some directories on $PATH contain the command), and I
suspect that the phrasing differences when we _do_ tell the human
user what we failed to run does not matter all that much.
