[bug#68180,1/4] gnu: emacs: Add awk, find, sed and sh to PATH wrapper.

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
---

 gnu/packages/emacs.scm | 21 ++++++++++++++-------
 1 file changed, 14 insertions(+), 7 deletions(-)

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.

Cheers

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?

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.

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'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.

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.

👍

Hi!

Andrew Tropin <andrew@trop.in> writes:

[...]

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

OK, thanks for clarifying!  You'll see this done in the v2 already sent
to this ticket.

Hi,

Maxim Cournoyer <maxim.cournoyer@gmail.com> writes:

> Hi!
>
> Andrew Tropin <andrew@trop.in> writes:
>
> [...]
>
>> I'm more on the "patching the references exactly" side to avoid the
>> problem mentioned above.
>
> OK, thanks for clarifying!  You'll see this done in the v2 already sent
> to this ticket.

I've now applied this to master, in its exact variant posted in v2.