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