[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: What 'sh' should 'system' use?
From: |
Philip McGrath |
Subject: |
Re: What 'sh' should 'system' use? |
Date: |
Mon, 26 Sep 2022 04:07:57 -0400 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.3.0 |
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