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

[Philip McGrath]

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