Follow-up Comment #4, bug #53201 (project make):
I don't understand the issue being reported. It would be greatly illuminating
if you could provide an example of the extra-long shebang line for me to
examine. I've tried for a bit to reproduce the problem and cannot. It's not
clear from your report whether it's the path to the interpreter which is too
long, or whether it's an argument to the interpreter which is too long.
The situation cannot be as simple as you suggest. First, the exec operation
that make invokes is in a forked process (obviously) so even if we were to try
to catch the ENOENT error, we couldn't do anything about it in the main make
process. It doesn't know anything about failures during exec in its child
process (it only knows when the child process exits, whether it had an error
or not).
Second, make itself never tries to parse the shebang line in a script. It
merely runs the program as provided to it. Make uses the execvp() function in
the forked process to invoke the command and this function performs PATH
lookup then invokes execve() (according to the GNU/Linux man page, these
functions are wrappers around execve()).
If the way make is invoking processes and the way the shell invoke them are
different then I can only put it down to differences in the way that the shell
and the execvp() function in GNU libc treat interpreter scripts. I'm not sure
I can see what GNU make should do about this difference.
_______________________________________________________
Reply to this item at:
<http://savannah.gnu.org/bugs/?53201>
_______________________________________________
Message sent via/by Savannah
http://savannah.gnu.org/
_______________________________________________
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make
