8 ms·
>But... "the shell and standard utilities and files that are in known locations and standard capabilities and various other things" are also specified by POSIX.
by faho 4y ago
>But... "the shell and standard utilities and files that are in known locations and standard capabilities and various other things" are also specified by POSIX.
Unfortunately, it doesn't specify those known locations. It explicitly declines specifying that /bin/sh exists.
https://pubs.opengroup.org/onlinepubs/9699919799/utilities/sh.html https://pubs.opengroup.org/onlinepubs/9699919799/utilities/s... says:
> Applications should note that the standard PATH to the shell cannot be assumed to be either /bin/sh or /usr/bin/sh, and should be determined by interrogation of the PATH returned by getconf PATH, ensuring that the returned pathname is an absolute pathname and not a shell built-in.
and it doesn't specify the location of getconf either, so you have a chicken-and-egg problem where you need the standard $PATH to find getconf to get the standard $PATH.
- vbezhenar 4y agoIt seems to be a convention those days to use `#!/usr/bin/env sh`. At least it's a single entry point. Why can't we just write `#!sh` I never understood. Another interesting snippet from your link: "Furthermore, on systems that support executable scripts (the "#!" construct), it is recommended that applications using executable scripts install them using getconf PATH to determine the shell pathname and update the "#!" script appropriately as it is being installed (for example, with sed)." So there could be systems which does not support shebang yet claiming to be POSIX?
- cperciva 4y agoWhy can't we just write `#!sh` I never understood. It's because #! is handled by the kernel, but the process environment is not parsed by the kernel.
- vbezhenar 4y agoParsing PATH should not be that hard.
- bregma 4y agoSure add arbitrary user input string parsing to the privileged kernel in a place where programs are launched. The CVE database is pretty sparse as it is and could use a good churning. So, assuming the string is parsed safely and securely, does the kernel have enough semantic knowledge of paths to know which service to pass it to? Are the services guaranteed to be loaded and running at all times? Or is there an underlying architectural assumption that the kernel is a Linux-style monolith and POSIX no longer applies to micro- and nano-kernel systems?
- cperciva 4y agoIt isn't... now. On a PDP-11 with 40 kW of RAM, on the other hand...
- cperciva 4y agoIf you have a shell: # command -p getconf PATH If you're writing C code of course you just use the library function.
- kevin_thibedeau 4y agoThis is particularly an issue with Solaris where the POSIX binaries are in their own directories.
- Karellen 4y ago> It explicitly declines specifying that /bin/sh exists. Huh. TIL. I've worked with POSIX for a couple of decades now, and I was sure that it required `/bin/sh` to be a valid path to the shell. Thanks!