Re: What 'sh' should 'system' use?

[Liliana Marie Prikler]

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