[Top][All Lists]

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

Re: shell function: confusing error when shebang incorrect

From: Paul Smith
Subject: Re: shell function: confusing error when shebang incorrect
Date: Sun, 09 Oct 2022 13:29:29 -0400
User-agent: Evolution 3.46.0 (by Flathub.org))

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.

reply via email to

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