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
