bug-make
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: shell function: confusing error when shebang incorrect


From: Kirill Elagin
Subject: Re: shell function: confusing error when shebang incorrect
Date: Sun, 9 Oct 2022 13:08:52 -0400

On Sun, Oct 9, 2022 at 11:57 AM <rsbecker@nexbridge.com> wrote:
> The interpretation of a bad shebang is platform-specific and has no single 
> consistent interpretation. Some platforms will report EPERM, EACCESS, or 
> ENOENT. The error is not necessarily under bash or zsh control but could come 
> from exec[vpe] depending on the platform. I am not sure a good fix is 
> practical for this situation. A similarly ambiguous problem happens when the 
> shebang is delegated to /bin/env for resolution instead of bash/zsh.

I am not convinced that platform-specific handling is not practical,
given that there is already a bunch of ifdefs going on in the code.
But anyway, let me emphasise one particular aspect of this.

The documentation of the `shell` function pretty directly states that
it will launch the shell, no exceptions, therefore, when I see an
error, I fully expect it to be coming from the shell.
I am very familiar with the behaviour of my shell, on my platform, so,
based on the documentation, I expect “bad interpreter” if the
interpreter is bad, and “no such file” only if the executable is not
found. When I see “no such file” I know not to question the
interpreter.
What was supposed to be a transparent optimisation, results, in fact,
in an undocumented change of the behaviour, which takes the user
minutes or tens of minutes to understand the cause (speaking from my
own experience helping someone to debug this).

How about this then: try to do the optimisation, but if `execve` fails
(for whatever reason), silently fallback to calling the shell and
letting it report the error?

Kirill



reply via email to

[Prev in Thread] Current Thread [Next in Thread]