On 19-09-2022 02:13, Philip McGrath wrote:
1) If we want to continue to hard-code a specific shell into Glibc,
We do, for reproducibility -- otherwise, the behaviour of the 'system' function depends on whatever is the current /bin/sh, and sometimes /bin/sh is updated (and on some foreign systems it might not even be the bash we are used to).
I think we
should document the decision (for example, why 'bash-static' vs. 'bash- minimal'?)
Because cycles -- bash-minimal is linked to a (shared) glibc, which is a separate package from bash-minimal, so glibc cannot use bash-minimal, it uses bash-static instead which is linked to a (static) glibc (which might use a bootstrap bash (not 100% sure), but it's statically linked, so no reference to the bootstrap bash remains IIUC).
Also, why? This is an implementation detail. Who would the target audience be for this documentation?
and recommendations for how packages should use it: '_PATH_BSHELL' is the best mechanism I've heard of so far, though I wish it were standardized, and the fact that it can't be portably assumed to be a string constant could be surprising.
I consider _not_ using it, and using (4) instead, to be best.If not suitable (for example, because a shell is needed to run an actual shell script), then a plain "sh" looked up in the $PATH (like other binaries) and substitute*-ed by Guix should suffice.
2) If we want to make 'sh' a weak/dynamic reference, I think we should strongly consider arranging to make it available at '/bin/sh' when present. I expect this option would require less patching of other packages*by far* than any other approach.
See (1) (reproducibility) -- also, you would need to modify the daemon for that, so there are compatibility concerns, and then we're stuck with the /bin/sh special case forever (unless breaking compatibility would later be considered acceptable).
3) If we want a dynamic 'sh' not located at '/bin/sh', I think we should implement a function similar to '__bionic_get_shell_path()' and use it for '_PATH_BSHELL', 'system', etc. That begs the question of how the function should find 'sh', and I don't have an answer for that.
How about $PATH?
In principle, we could design a configuration mechanism for 'confstr(_CS_PATH, buf, sizeof(buf))' and use it to find the shell: that has some appeal, but making the mechanism extensible enough to support "all of the standard utilities of POSIX.1-2017" seems like a challenge. What do you think?
(4) Stop using 'system' in applications -- instead use whatever the language's equivalent of Guile's system*, execl ... or Guix' 'invoke'. Why? Because 'system'-like functions requires quoting the command line arguments whereas in 'system*'-like functions you could just pass a list of command line arguments, and it's easy to get the quoting wrong, especially if some of the arguments are generated dynamically.
As a bonus, this could often remove a dependency on bash{-minimal,-static,}.Maybe we can eventually remove _PATH_BSHELL and 'system' from our glibc (and Guile, ...).
Greetings, Maxime.
OpenPGP_0x49E3EE22191725EE.asc
Description: OpenPGP public key
OpenPGP_signature
Description: OpenPGP digital signature