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