Nice, PT_INTERP is the only non-relocatable thing of ELF files and typically requires wrapper scripts/executables.

Regarding shebangs, I've never understood why the kernel cannot resolve e.g. `#!sh` relative to PATH instead of CWD. Posix prescribes that you should look for `sh` in PATH and don't expect it to be in `/bin/sh`. And using `/usr/bin/env sh` has the same issue: what if coreutils is installed elsewhere.

▲ pm215 8 hours ago | parent | next [-]

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 7 hours ago | parent [-]

> 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 6 hours ago \| parent [-]
		To 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`

▲ inigyou 7 hours ago | parent | prev [-]

The kernel never looks at PATH, that's why. It's a shell construct.

▲

mort96 7 hours ago | parent [-]

... and the question was: "Why doesn't the kernel look at PATH"

It's not a "shell construct" either, the standard execvp libc function looks at PATH.

▲

inigyou 5 hours ago | parent | next [-]

A surprising number of things in Linux are transparent to the kernel as they are implemented in user space. For instance, the Linux kernel doesn't support multithreading. It only supports processes sharing an address space. Which is what most people call threads - but in the kernel, they are just processes that happen to share an address space.

	▲	skissane 2 hours ago \| parent [-]
		> the Linux kernel doesn't support multithreading. It only supports processes sharing an address space. Which is what most people call threads - but in the kernel, they are just processes that happen to share an address space. This isn’t really true. It is just that internally, the kernel calls the thread ID “pid” and the process ID “tgid” (“thread group ID”). But the getpid system call returns the “tgid” not the “pid”, and to get the “pid” you need to call gettid (get thread ID). Other kernel interfaces also use the terminology “thread”, e.g. /proc/thread_self, set_tid_address, set_thread_area/get_thread_area, the CLONE_THREAD flag to clone, inter alia

▲

stabbles 7 hours ago | parent | prev [-]

Indeed, it's a libc construct.