[bug#57050] [PATCH v2 04/13] gnu: Add Zuo.

["Philip McGrath" <philip@philipmcgrath.com>]

On Tue, Aug 23, 2022, at 5:20 AM, Maxime Devos wrote:
>> [...]
>> I will use GUIX_SH in v3 of this series.
>>
>> My concern with it originally was that it's generic enough that it might be used in other ways elsewhere in Guix, but, since I'm hoping it's only going to be a medium-term solution, it seems good enough, and I haven't heard any objections to it.
> _PATH_BSHELL seems better to me, as it is not Guix-specific and does not 
> require adding preprocessor arguments.

Not needing preprocessor arguments would be a nice advantage. I will try _PATH_BSHELL.

> Even simpler would be to 
> substitute* the /bin/sh to (search-input-file inputs "bin/sh") like done 
> for other packages.
>

Unfortunately, that doesn't work well here. We cannot refer to store paths in Racket or Chez source code (as opposed to C code) because the grafter cannot handle the format of compiled code: see <https://issues.guix.gnu.org/47180#6>. (I don't know about Zuo image dumps, but the binary format is unspecified, so it seems safer not to.)

Also, especially for Racket, there are many entry points where "/bin/sh" might come from, including both functions like 'system' and also programs that explicitly use "/bin/sh" with functions like 'system*'. When I first wrote the current patch, maintaining Guix-specific patches for all of them seemed unsustainable, so I instead patched the low-level function for running subprocesses to interpose on any attempt to execute "/bin/sh", regardless of where it came from.

If I addressed this upstream, I'd probably extend an existing function to support `(find-system-path 'shell)`, change `system` and friends to use it, and likewise change scripts that currently use "/bin/sh" explicitly.

> On 23-08-2022 03:40, Philip McGrath wrote:
>> First of all, I have found that there*is*  another Unix-like system where "/bin/sh" doesn't exist: on Android, the POSIX shell is usually at "/system/bin/sh". Also, at least on some versions, _PATH_BSHELL isn't a compile-time constant. It is:
>>
>>      #define _PATH_BSHELL __bionic_get_shell_path()
>
> Looking at the patch, it not being a compile-time constant does not 
> appear to be a problem to me.
>

It's not an issue with the current patch. It could be relevant for some ways of addressing this upstream. Mostly, it's part of my thinking that "where is the shell, if any?" is a question best answered at runtime rather than compile time.

-Philip