3 ms·

Nice, PT_INTERP is the only non-relocatable thing of ELF files and typically requires wrapper scripts/executables. Regarding shebangs, I've never understood wh

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 3mo 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 3mo 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 3mo ago
    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 3mo ago
The kernel never looks at PATH, that's why. It's a shell construct.
- mort96 3mo ago
  ... 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.
  - stabbles 3mo ago
    Indeed, it's a libc construct.
  - inigyou 3mo ago
    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 3mo ago
      > 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 3mo ago
        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".

pm215 3mo 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 3mo 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 3mo ago
  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 3mo ago

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

mort96 3mo ago
... 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.
- stabbles 3mo ago
  Indeed, it's a libc construct.
- inigyou 3mo ago
  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 3mo ago
    > 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 3mo ago
      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".