Re: shell function: confusing error when shebang incorrect

[David Boyce]

I have a feeling I may be treading over old ground here but wouldn't a simple solution be to simply abandon fast-path for explicit $(shell ...) invocations? After all, as Kirill says:

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

There's some difference IMHO between a recipe invocation, which only implicitly invokes the shell (leaving aside the fact that POSIX says it does so), and a direct, specific request to invoke the shell via the $(shell ...) function. Why not say "if you explicitly ask for the shell, you get the shell"?

In my experience the number of explicit $(shell ...) invocations is usually a tiny fraction of the number of recipes run. And if someone did write a makefile in which $(shell ...) uses dominated they'd have written a shell script in make syntax and the answer should be "don't do that".

David

On Sun, Oct 9, 2022 at 1:29 PM Paul Smith <psmith@gnu.org> wrote:

On Sun, 2022-10-09 at 13:08 -0400, Kirill Elagin wrote:
> 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.
>
> 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.

Yes, but they are largely for supporting completely different OSs, like
Windows, VMS, AmigaOS, etc.  We generally hope to not have to support
differences in behavior between BSD, Linux, different libc
implementations like GNU, MacOS, etc. etc.

In in any event, in order to have this work, make would have to detect
the failure, then open the first line of the file and parse it to see
if it started with #! (only on systems where this is supported) then if
so parse the #! line to see what the interpreter path was, then examine
the interpreter path to determine its status.

It could be done but it's not pretty; also see below.

> 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?

This has been considered and might be implemented.  It's not quite so
pretty however because make forks a new process then runs exec, and
it's not until the latter that we actually determine if there's an
issue or not.  This means that the reworking of the command must be
done in the forked process.  This is messy since we use vfork where
available and the things you can do in a vfork'd process before exec
are much more limited.  For example, things like allocating memory are
not a good idea.

Again, it could be done but it's not simple.  Probably what we'd have
to do is compute both the fast-path and slow-path invocations in the
parent make, so that the forked process could use either one without
having to construct anything on its own.