RE: shell function: confusing error when shebang incorrect

[rsbecker]

On October 9, 2022 11:16 AM, Kirill Elagin wrote:
>There is a bit of unexpected behaviour in the `shell` function (due to the
>undocumented fact that it sometimes avoids actually calling the
>shell):
>
>```
>$ cat Makefile
>FOO:=$(shell ./foo.sh)
>
>$ cat foo.sh
>#!/bin/ohno
>echo hi
>
>$ make
>make: ./foo.sh: No such file or directory
>make: *** No targets.  Stop.
>
>$ ./foo.sh
>zsh: ./foo.sh: bad interpreter: /bin/ohno: no such file or directory ```
>
>The “no such file or directory” error from Make is very confusing and 
>unexpected
>in this situation, especially given that it is not the error that the shell 
>would return.
>
>The reason for it is that, while undocumented, the `shell` function will try 
>to avoid
>calling the shell in simple cases like this one and will directly exec the 
>command.
>However, the error returned by `execve` is ambiguous:
>
>> ENOENT  The file pathname or a script or ELF interpreter does not exist.
>
>Shells (bash, zsh) disambiguate it themselves, i.e. there is extra logic for 
>the case
>of ENOENT, while Make simply fails with what it sees, resulting in a puzzling 
>error
>message.

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.
-Randall