Thanks for looking into this.
I guess this shows it isn't always helpful to just pass down error
messages. Bash knows it's trying to execute something. It doesn't work
out. For the naive user of a shell, it would be more helpful to have it
come back with:
Couldn't execute ...
Because the problem is, it can't execute the requested file. A more
descriptive error from the kernel would be great, but if that's not
available, bash should be aware of what it's trying to do, and give back
an appropriate error. This is just wrong. If I do /ewdedwededqwd bash
comes back with the same message. Strace in this case will say "Can't
stat", not "exec: No such file or directory"
Peter
On 06/05/2560 07:59, Eduardo Bustamante wrote:
> On Fri, May 5, 2017 at 7:44 PM, Peter Passchier <pe...@passchier.net> wrote:
> [...]
>> The output from bash is misleading. The file is there. Couldn't the
>> error message be more descriptive of what's the actual problem?
>
> Bash has no way of knowing what the problem is. Bash will do:
>
> execve("...")
>
> to the binary you provided. The kernel will then return "ENOENT" (from
> https://linux.die.net/man/2/execve, "ENOENT - The file filename or a
> script or ELF interpreter does not exist, or a shared library needed
> for file or interpreter cannot be found."). Bash sees the ENOENT
> error, and prints the strerror() corresponding to that error, which is
> "No such file or directory".
>
> Bash would need an error code more specific than ENOENT from the
> kernel to be able to distinguish between. ENOLIB or something.
>
> Most likely no other shell or tool does this anyways. You can see that
> strace tries to execve the tool, and it prints the same error as bash.
>
