~sircmpwn/hare#959: ensuring $PATH lookup behaves as expected

We should invest some time into figuring out how closely os::exec::lookup and os::exec::lookup_open should follow POSIX and how much we should do to follow local customs on each platform.

We won't be able to completely match libc's exec*p* behavior in lookup, because of separated lookup and exec stages, so we should also take into account all the potential differences between os::exec::lookup and os::exec::lookup_open that could arise from that.

~turminal added design 3 months ago

~turminal added stdlib 3 months ago

~sebsite 2 months ago

I imagine we probably don't want to replicate libc's behavior of consulting confstr(_CS_PATH) if PATH isn't defined (right?)

We won't be able to completely match libc's execp behavior in lookup, because of separated lookup and exec stages

Why not?

~turminal 2 months ago

This is actually one of the bits of POSIX that neither Linux nor *BSD seem to adhere to particularly strictly. They do have a default in case $PATH is undefined, but at least on Musl, it does not match the value of confstr(_CS_PATH).

Why not?

Because it is implemented as one big loop that attempts to execve concatenations of consecutive path components and the executable name, and checking all the potential error conditions of execve without actually calling it would be a lot of work, if it is possible at all.

See NetBSD and Musl implementations (BSDs all do largely the same thing).