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

[Philip McGrath <philip@philipmcgrath.com>]

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.

>> 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.

>> 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.

>>> In versions of glibc before 2.1.3, [...] system() always returned
>>> 1 [...].
> Note that always returning non-zero is required by POSIX 2017.
> 

To quote the whole paragraph from
<https://pubs.opengroup.org/onlinepubs/9699919799/functions/system.html>:

> Note that, system(NULL) is required to return non-zero, indicating
> that there is a command language interpreter. At first glance, this
> would seem to conflict with the ISO C standard which allows
> system(NULL) to return zero. There is no conflict, however. A system
> must have a command language interpreter, and is non-conforming if
> none is present. 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. Guix creates many environments that do not conform to 
POSIX.1-2017: for example, any environment without `vi`.

-Philip