guix-patches
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Maxim Cournoyer
Subject: [bug#68180] [PATCH 1/4] gnu: emacs: Add awk, find, sed and sh to PATH wrapper.
Date: Mon, 01 Jan 2024 21:07:36 -0500
User-agent: Gnus/5.13 (Gnus v5.13)

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.

-- 
Thanks,
Maxim





reply via email to

[Prev in Thread] Current Thread [Next in Thread]