Re: non-executable files in $PATH cause errors

[Chet Ramey]

On 1/14/21 5:15 AM, Robert Elz wrote:


> I suspect what you're being confused by, is that the "searches for" is
> typically done (in shells, I have no idea what the code inside bash is
> like) by simply taking each element of PATH, appending "/command_name"
> and attempting an exec.   If that succeeds, the command is running, and
> everyone is happy (exec*(2) only work for executable files - ones with
> the appropriate 'x' bit (or any if the caller is root) set).

No shell that uses a hash table for commands does it this way. Historical
shells (by which I mean the v7 sh) probably did. It's more likely that
modern shells attempt to determine executability using stat(2) or access(2)
instead of attempting an execve(2), so the parent shell can maintain its
hash table.

> If the exec fails, then the shell does some saving of the error number
> returned - more or less ignoring "file not found" type errors, but saving
> the error number from the first attempt that failed for some different
> reason.

When bash was written, the BSD shell was the very lightly modified v7 sh
they used up until 4.4 BSD. That shell did exactly this: it reported the
error from the first non-executable version of a command it found during a
PATH search for a name if it didn't find an executable file with that name.

So bash, in order to be compatible with the shell on systems GNU software
targeted at the time, kept track of the first non-executable file it found
in $PATH and reported the error from that. It still does, now to be 
compatible with itself.

--
``The lyf so short, the craft so long to lerne.'' - Chaucer
                 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU    chet@case.edu    http://tiswww.cwru.edu/~chet/