On 2024-01-01 21:07, Maxim Cournoyer wrote:

> Hi Andrew,
>
> Andrew Tropin <andrew@trop.in> writes:
>
> [...]
>
>>>> We already have a phase to patch in the real path of /bin/sh where it's
>>>> used.  This appears to be an odd case that's missed.
>>>
>>> I appreciate exactness, but it seems fragile to rely on nobody adding
>>> new references or someone catching them as new Emacs modules get added
>>> or changed :-).
>>>
>>> My reasoning was that since Emacs already depends on bash, why not
>>> ensure it'll always be found on PATH, by wrapping instead of
>>> substituting.
>>>
>>> Does it make sense?
>>
>> Yep, make sense to me. I also find cases from time to time, when some
>> binary or another isn't found by some elisp code.
>>
>> However, providing those binaries via PATH can make some code or
>> programs to work, when executed from inside Emacs and not to work in the
>> environment outside, which can be really confusing in some cases.
>>
>> A simple example, imaging we have a script: 1.sh, which contains:
>> sh --version
>>
>> This one will work:
>> guix shell emacs-with-bash --pure -- emacs --eval '(shell-command "./1.sh")'
>>
>> This one will not:
>> guix shell emacs-with-bash --pure -- ./1.sh
>>
>> That said, the idea of patching all the pathes to binaries seems better
>> to me.
>
> I'm not sure if I got you correctly: do you prefer to wrap Emacs with
> the tools it needs in PATH, or patch the references exactly in its
> source, as Liliana suggested?

I'm more on the "patching the references exactly" side to avoid the
problem mentioned above.

>
> I've tried the "exact" patch suggested by Liliana in v2.  I tested that
> reading a manual page was possible in a containerized environment still
> worked.

👍

-- 
Best regards,
Andrew Tropin