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

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.