Re: [BUG] Git 2.38.0-rc1 t1800 message text comparison

From: Junio C Hamano <gitster@pobox.com>
Date: Jun 6, 2023, 00:31 UTC
Message-ID: <xmqqwn0h4ek3.fsf@gitster.g>
In-Reply-To: <28d808e4-77b4-d91e-8a86-c21287019b56@web.de>

René Scharfe <l.s.r@web.de> writes:

Show 5 quoted lines

> 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.