4 ms·
I suspect it's a mix of historical reasons (#! support was added pretty early, in 1980 or so, when the unix development philosophy I think tended quite strongly
by pm215 2mo ago
I suspect it's a mix of historical reasons (#! support was added pretty early, in 1980 or so, when the unix development philosophy I think tended quite strongly to "do the simple thing", and there wasn't so much variation in where you might put important binaries like the shell), plus the fact that the kernel doesn't know anything about PATH (it's only your shell that does), plus vague worries about potentially accidentally breaking existing #! lines that used to work.
- chuckadams 2mo ago> plus the fact that the kernel doesn't know anything about PATH (it's only your shell that does) glibc is what deals with PATH, not the shell. On Linux, it's execvp(3) in libc which is implemented in terms of execve(2) in the kernel, but POSIX doesn't make a distinction between syscalls and library functions, so a kernel could implement either or none directly.
- stabbles 2mo agoTo be fair, many shells have command caching, so they effectively roll their own exec syscall wrapper: $ python3 -c 'print("hi")' hi $ hash hits command 1 /usr/bin/python3