On Sun, Oct 9, 2022 at 11:57 AM <rsbec...@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
