[stabbles]

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]

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]

> 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]

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]

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

[mort96]

... 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]

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]

> 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

[_nalply]

I found grandparent's post still useful because it caused something to click in my head. I then researched and found that threads and processes share a lot of functionality. In the kernel both processes and threads are represented by `task_struct` instances.

So, respectfully, you shouldn't dismiss grandparent with "This isn't really true".

[skissane]

It is true that the Linux kernel partially unifies the concepts of process and thread into "task"

It is false that it doesn't have the concept of processes and threads, or the distinction between them

What I was saying "isn't really true" is the second claim, not the first claim

[stabbles]

Indeed, it's a libc construct.