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.