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.ra...@case.edu> wrote: > On 11/2/24 8:43 AM, hmms...@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 c...@case.edu http://tiswww.cwru.edu/~chet/ >
