Hi, Am Montag, dem 26.09.2022 um 04:07 -0400 schrieb Philip McGrath: > Hi, > > On 9/19/22 03:07, Liliana Marie Prikler wrote: > > Am Sonntag, dem 18.09.2022 um 20:13 -0400 schrieb Philip McGrath: > > > On the other hand, even Nix puts '/bin/sh' at its usual path: we > > > are really quite an outlier in this respect. (IIUC, Nix also has > > > '/usr/bin/env', but no other utilities at FHS paths.) > > We are not. We provide both /bin/sh and /usr/bin/env. If you're > > talking about the build container then that's a much smaller > > distinction. > > > > Yes, I'm talking about the build container. But for the build > container, programs/libraries that use "/bin/sh" would work > unmodified. I think there's limited value in having them work unmodified; see ‘patch-source-shebangs’.
> > > More broadly, I now think it would be better in we embedded zero > > > references to copies of Bash in libc. > > I don't think we can do that without breaking system. > > > > When "/bin/sh" is not available at runtime, I think libc's `system` > ought to return 127, and other `system`-like functions should raise > exceptions or whatever the idiomatic way is to signal failure. Of > course, we will presumably need to make "/bin/sh" available in many > more places, but don't think it's surprising for programs that need > to run shell commands to fail in the absence of a shell. Au contraire, I'd argue that people who use system will be the most surprised when it actually does fail. > > > However, giving every program using Glibc a hard dependency on > > > Bash—and on a particular Bash executable—seems like a much bigger > > > imposition. > > We're talking 1.7 MiB here. Certainly a "big" imposition, but > > nothing in comparison to the things you need in the store for > > bootstrapping purposes. Also note that bash-minimal, while only > > taking up 1.0 MiB for itself, requires both glibc and gcc:lib, > > which apart from creating a cycle does blow up its closure size > > quite a bit. > > > > I'm less concerned with the literal size than with the significance > of putting a specific shell so near the root of most dependency > graphs: I tried to give examples in my reply to Maxime, like creating > containers without a shell. What is this significance? From the examples you gave Maxime, I find it insignificant. > > > > > It is therefore permissible for the system() function on such a > > system to implement the behavior specified by the ISO C standard as > > long as it is understood that the implementation does not conform > > to POSIX.1-2017 if system(NULL) returns zero. > > I understand that to mean that `system(NULL)` returning zero > indicates that the program is not (currently) running in a POSIX.1- > 2017 environment. This test is severely broken. It fails to account for non-POSIX.1-2017 systems, that nevertheless return 1. >From the GNU coding standards [1]: > The GNU Project regards standards published by other organizations as > suggestions, not orders. We consider those standards, but we do not > “obey” them. In developing a GNU program, you should implement an > outside standard’s specifications when that makes the GNU system > better overall in an objective sense. When it doesn’t, you shouldn’t. Here, conforming to POSIX makes sense: it improves portability at little cost. > Guix creates many environments that do not conform to POSIX.1-2017: > for example, any environment without `vi`. Here it doesn't. The convenience of vi is highly debatable. Cheers
