GNU bug report logs - #68180
[PATCH 0/4] Add emacs-pde

Previous Next

Full log

View this message in rfc822 format

From: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
To: Andrew Tropin <andrew <at> trop.in>
Cc: 68180 <at> debbugs.gnu.org, Katherine Cox-Buday <cox.katherine.e+guix <at> gmail.com>, Liliana Marie Prikler <liliana.prikler <at> gmail.com>
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

Hi Andrew,

Andrew Tropin <andrew <at> 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

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.