[PATCH] posix: execvpe: skip $PATH components that are too long

[Collin Funk]

Paul Eggert <eggert@cs.ucla.edu> writes:

> On 2025-11-08 09:09, Bruno Haible wrote:
>> The kernel will return ENAMETOOLONG for attempts
>> to access D1/F. However, this does *not* mean that F does
>> not exist in F1. Therefore, it does *not* mean that D2/F
>> should be picked and executed.
>
> I'm not quite seeing that. POSIX says that the search continues "until
> an executable file with appropriate execution permissions is found"[1]
> so it boils down to what is meant by "found". My interpretation is
> that ENAMETOOLONG means such a file is not "found" there, so the
> search should continue.
>
> For what it's worth, FreeBSD execvpe[2] treats ENAMETOOLONG the same
> way as the proposed patch.
>
> FreeBSD puts ELOOP into the same category as ENOENT/ENAMETOOLONG/etc.,
> and it would make sense to add ELOOP while we're in the neighborhood.
> That is, a symlink loop should not prevent execvpe from looking later
> in PATH, as such a loop means the file was not "found" at the current
> spot.

The POSIX page for the execs function states [1]:

    The exec functions, except for fexecve(), shall fail if:

    [ENAMETOOLONG]
        The length of a component of a pathname is longer than
        {NAME_MAX}.

So shouldn't the current behavior be correct?

POSIX may want to change that if other implementations don't fail,
though.

Collin

[1] https://pubs.opengroup.org/onlinepubs/9799919799/functions/exec.html