Re: degraded error message in case of hash-bang interpreter error

[Martin D Kealey]

This is one of those cases I would file under "POSIX being annoyingly
literal".

POSIX says that the execve syscall reads the name of an interpreter (and
options) from a '#!' line, prefaces them onto the front of argv, and then
restarts itself. This is why some people argue that ENOENT is "logical" the
interpreter can't be found. (And to be fair, Linux seems to apply this to
*any* missing "interpreter", including the ELF loader.)

However, for every other syscall, ENOENT means that the supplied pathname
can't resolve. It's crazy to have "access" and "stat" say "OK" but "execve"
say "File does not exist".

To my mind, the name of the interpreter is an internal detail, so a more
logical error to return would be ENOEXEC aka 'Exec format error'. It would
be a trivial change to have execve flag when it restarts itself, and when
it later can't find the executable, it can return -ENOEXEC instead of
-ENOENT.

-Martin

On Sun, 3 Nov 2024 at 05:13, Chet Ramey <chet.ramey@case.edu> wrote:

> On 11/2/24 8:43 AM, hmmsjan@kpnplanet.nl wrote:
>
> > Bash Version: 5.2
> > Patch Level: 9
> > Release Status: release
> >
> > Description:
> >     If the interpreter after #! is wrong, a non-informative message
> prints
> >
> > Repeat-By:
> >       "unix2dos bashscript" starting with #!/bin/bash
> >       ./bashscript
> >        bash: ./bashscript: cannot execute: required file not found
>
> This was changed a couple of years ago, as the result of
>
> https://lists.gnu.org/archive/html/bug-bash/2022-10/msg00051.html
>
> --
> ``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/
>