On 2023-12-31 16:10, Maxim Cournoyer wrote:

> Hi Liliana,
>
> Liliana Marie Prikler <liliana.prikler@gmail.com> writes:
>
>> Am Sonntag, dem 31.12.2023 um 11:59 -0500 schrieb Maxim Cournoyer:
>>> Before this change, using Emacs in a pure environment, e.g. 'guix
>>> shell --pure emacs', would cause problems such as:
>>> 
>>>   jka-compr-insert-file-contents: Uncompression program ‘sh’ not
>>> found
>>> 
>>> And other problems were found requiring the other tools.  While the
>>> above could be patched in place for 'sh', it seems more robust and
>>> universally useful to have the commands appear on PATH, should other
>>> Elisp modules want to call to these directly as well.
>>> 
>>> * gnu/packages/emacs.scm (emacs-minimal) [arguments] <phases>: Adjust
>>> the
>>> wrap-emacs-paths phase to wrap additional inputs.
>>> [inputs]: Add findutils, gawk and sed.
>>> (%emacs-modules): Add (srfi srfi-26).
>>> 
>>> Change-Id: Ifb4fe2fc12ddc9eae387adb3da3f7821fab78e65
>>> ---
>> 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.

-- 
Best regards,
Andrew Tropin