GNU bug report logs -
#73416
[PATCH core-updates] build: Set $0 to basename of command in `wrap-program'.
Previous Next
To reply to this bug, email your comments to 73416 AT debbugs.gnu.org.
There is no need to reopen the bug first.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
andreas <at> enge.fr, ludo <at> gnu.org, guix-patches <at> gnu.org
:
bug#73416
; Package
guix-patches
.
(Sun, 22 Sep 2024 06:08:01 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
:
New bug report received and forwarded. Copy sent to
andreas <at> enge.fr, ludo <at> gnu.org, guix-patches <at> gnu.org
.
(Sun, 22 Sep 2024 06:08:01 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
* guix/build/utils.scm (wrap-program): Set the value of the -a option of
`exec' in the wrapper to ${0##*/} instead of $0, to use its base name instead
of the complete file name.
Fixes: https://issues.guix.gnu.org/73405
Change-Id: Iec5984d4d934c8df88a90ff653947f7d07413ae4
---
guix/build/utils.scm | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/guix/build/utils.scm b/guix/build/utils.scm
index 94714bf397..7003d8262f 100644
--- a/guix/build/utils.scm
+++ b/guix/build/utils.scm
@@ -1355,7 +1355,7 @@ (define* (wrap-program prog #:key (sh (which "bash")) #:rest vars)
#!location/of/bin/bash
export PATH=\"/gnu/.../bar/bin\"
export CERT_PATH=\"$CERT_PATH${CERT_PATH:+:}/gnu/.../baz/certs:/qux/certs\"
- exec -a $0 location/of/.foo-real \"$@\"
+ exec -a \"${0##*/}\" location/of/.foo-real \"$@\"
This is useful for scripts that expect particular programs to be in $PATH, for
programs that expect particular shared libraries to be in $LD_LIBRARY_PATH, or
@@ -1432,7 +1432,7 @@ (define* (wrap-program prog #:key (sh (which "bash")) #:rest vars)
(call-with-output-file prog-tmp
(lambda (port)
(format port
- "#!~a~%~a~%exec -a \"$0\" \"~a\" \"$@\"~%"
+ "#!~a~%~a~%exec -a \"${0##*/}\" \"~a\" \"$@\"~%"
sh
(string-join (map export-variable vars/filtered) "\n")
(canonicalize-path wrapped-file))))
base-commit: 2c54c2db410ebdda8cd71716315e4ea4d31befbd
--
2.46.0
Reply sent
to
Ludovic Courtès <ludo <at> gnu.org>
:
You have taken responsibility.
(Sat, 22 Mar 2025 22:36:02 GMT)
Full text and
rfc822 format available.
Notification sent
to
Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
:
bug acknowledged by developer.
(Sat, 22 Mar 2025 22:36:03 GMT)
Full text and
rfc822 format available.
Message #10 received at 73416-done <at> debbugs.gnu.org (full text, mbox):
Maxim Cournoyer <maxim.cournoyer <at> gmail.com> skribis:
> * guix/build/utils.scm (wrap-program): Set the value of the -a option of
> `exec' in the wrapper to ${0##*/} instead of $0, to use its base name instead
> of the complete file name.
>
> Fixes: https://issues.guix.gnu.org/73405
> Change-Id: Iec5984d4d934c8df88a90ff653947f7d07413ae4
Applied to ‘core-packages-team’, thanks!
Ludo’.
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org
.
(Sun, 20 Apr 2025 11:24:12 GMT)
Full text and
rfc822 format available.
bug unarchived.
Request was from
Liam Hupfer <liam <at> hpfr.net>
to
control <at> debbugs.gnu.org
.
(Sun, 20 Jul 2025 02:02:02 GMT)
Full text and
rfc822 format available.
Information forwarded
to
guix-patches <at> gnu.org
:
bug#73416
; Package
guix-patches
.
(Sun, 20 Jul 2025 02:55:02 GMT)
Full text and
rfc822 format available.
Message #17 received at 73416 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Maxim Cournoyer <maxim.cournoyer <at> gmail.com> writes:
> * guix/build/utils.scm (wrap-program): Set the value of the -a option of
> `exec’ in the wrapper to ${0##*/} instead of $0, to use its base name instead
> of the complete file name.
>
> Fixes: <https://issues.guix.gnu.org/73405>
> Change-Id: Iec5984d4d934c8df88a90ff653947f7d07413ae4
I have a hacky extra wrap-program around Emacs (in a separate package so
I don’t have to rebuild Emacs), and this change (now on master after the
recent core-packages-team merge) seems to have broken it:
┌────
│ $ emacs
│ Error using execdir /gnu/store/0jz32qbcibz6y5xzm6jwzh0x8kviy9gz-emacs-pgtk-gtk-wrapper-30.1-1.a05be41/bin/:
│ emacs: /gnu/store/0jz32qbcibz6y5xzm6jwzh0x8kviy9gz-emacs-pgtk-gtk-wrapper-30.1-1.a05be41/bin/../native-lisp/30.1.90-f736b5c5/preloaded/window.eln: cannot open shared object file: No such file or directory
└────
It appears Emacs does some dubious things in ‘find_emacs_executable’;
namely, if you execute Emacs without a slash in ‘argv[0]’, it “resolves”
the path by just searching PATH for ‘argv[0]’. This heuristic is used to
find the native-lisp directory, and it breaks when a wrapper like this
is not in the same directory as the Emacs executable.
I am not really advocating for reverting this. I don’t think Emacs
should assume ‘argv[0]’ is correlated to the executable file name. I
just want to write this down in proximity to the change that exposed it.
I will probably report to Emacs since the C is relatively new.
—Liam
Information forwarded
to
guix-patches <at> gnu.org
:
bug#73416
; Package
guix-patches
.
(Mon, 21 Jul 2025 05:25:01 GMT)
Full text and
rfc822 format available.
Message #20 received at 73416 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Liam Hupfer <liam <at> hpfr.net> writes:
> I am not really advocating for reverting this. I don’t think Emacs
> should assume ‘argv[0]’ is correlated to the executable file name. I
> just want to write this down in proximity to the change that exposed it.
> I will probably report to Emacs since the C is relatively new.
I opened [bug#79064: native-lisp directory resolution shouldn’t depend on
Emacs filename resolution via argv[0]].
On second thought, though, I think we should consider reverting the
change to ‘wrap-program’. [bug#73405: wrap-program should use the
basename of $0 as arg0] does not describe why ‘cling’ was segfaulting,
but I suspect it’s due to similar bad assumptions about argv[0] as the
Emacs issue.
I think wrappers should be as transparent as possible—however the user
invokes a command should be preserved in argv[0], whether using a
basename with PATH resolution or a relative or absolute filename. We
shouldn’t coerce argv[0] to a basename when the wrapper wasn’t called
that way. 99% of the time argv[0] is irrelevant, but the common case I’m
considering is programs that log how they were called—it’s disorienting
for the wrapper to affect that.
Maybe we can expose an argument to wrap-program to use the basename
approach, but IMO we should be handling the root cause in cases where
problems occur and pushing upstreams to handle arbitrary argv[0] values
robustly.
WDYT? Thanks!
—Liam
[bug#79064: native-lisp directory resolution shouldn’t depend on
Emacs filename resolution via argv[0]] <https://yhetil.org/emacs/87h5z6p3m3.fsf <at> hpfr.net/>
[bug#73405: wrap-program should use the
basename of $0 as arg0] <https://yhetil.org/guix/87a5g1o8pc.fsf <at> gmail.com/>
Information forwarded
to
guix-patches <at> gnu.org
:
bug#73416
; Package
guix-patches
.
(Mon, 21 Jul 2025 12:03:01 GMT)
Full text and
rfc822 format available.
Message #23 received at 73416 <at> debbugs.gnu.org (full text, mbox):
Liam Hupfer <liam <at> hpfr.net> writes:
> On second thought, though, I think we should consider reverting the
> change to ‘wrap-program’. [bug#73405: wrap-program should use the
> basename of $0 as arg0] does not describe why ‘cling’ was segfaulting,
> but I suspect it’s due to similar bad assumptions about argv[0] as the
> Emacs issue.
>
> I think wrappers should be as transparent as possible—however the user
> invokes a command should be preserved in argv[0], whether using a
> basename with PATH resolution or a relative or absolute filename. We
> shouldn’t coerce argv[0] to a basename when the wrapper wasn’t called
> that way. 99% of the time argv[0] is irrelevant, but the common case I’m
> considering is programs that log how they were called—it’s disorienting
> for the wrapper to affect that.
>
> Maybe we can expose an argument to wrap-program to use the basename
> approach, but IMO we should be handling the root cause in cases where
> problems occur and pushing upstreams to handle arbitrary argv[0] values
> robustly.
>
> WDYT? Thanks!
This member of the peanut gallery supports the revert. Exactly as you
say, the wrappers should be as transparent as possible. So this
mangling feels wrong.
Tomas
--
There are only two hard things in Computer Science:
cache invalidation, naming things and off-by-one errors.
Information forwarded
to
guix-patches <at> gnu.org
:
bug#73416
; Package
guix-patches
.
(Wed, 23 Jul 2025 01:29:01 GMT)
Full text and
rfc822 format available.
Message #26 received at 73416 <at> debbugs.gnu.org (full text, mbox):
Hi,
Tomas Volf <~@wolfsden.cz> writes:
> Liam Hupfer <liam <at> hpfr.net> writes:
>
>> On second thought, though, I think we should consider reverting the
>> change to ‘wrap-program’. [bug#73405: wrap-program should use the
>> basename of $0 as arg0] does not describe why ‘cling’ was segfaulting,
>> but I suspect it’s due to similar bad assumptions about argv[0] as the
>> Emacs issue.
>>
>> I think wrappers should be as transparent as possible—however the user
>> invokes a command should be preserved in argv[0], whether using a
>> basename with PATH resolution or a relative or absolute filename. We
>> shouldn’t coerce argv[0] to a basename when the wrapper wasn’t called
>> that way. 99% of the time argv[0] is irrelevant, but the common case I’m
>> considering is programs that log how they were called—it’s disorienting
>> for the wrapper to affect that.
>>
>> Maybe we can expose an argument to wrap-program to use the basename
>> approach, but IMO we should be handling the root cause in cases where
>> problems occur and pushing upstreams to handle arbitrary argv[0] values
>> robustly.
>>
>> WDYT? Thanks!
>
> This member of the peanut gallery supports the revert. Exactly as you
> say, the wrappers should be as transparent as possible. So this
> mangling feels wrong.
After giving it some more thoughts, I agree. I think I had originally
worked under the assumption that $0 would always expand to the absolute
file name of the wrapper because of the wapper itself, but that's not
the case; $0 exactly matches the way the user or launcher called the
application, so it makes sense to preserve that information.
It'll have to be done on the next core-packages branch though, as it's a
world rebuild change.
--
Thanks,
Maxim
Information forwarded
to
guix-patches <at> gnu.org
:
bug#73416
; Package
guix-patches
.
(Wed, 06 Aug 2025 19:59:01 GMT)
Full text and
rfc822 format available.
Message #29 received at 73416 <at> debbugs.gnu.org (full text, mbox):
Maxim Cournoyer <maxim.cournoyer <at> gmail.com> writes:
> Hi,
>
> Tomas Volf <~@wolfsden.cz> writes:
>
>> Liam Hupfer <liam <at> hpfr.net> writes:
>>
>>> On second thought, though, I think we should consider reverting the
>>> change to ‘wrap-program’. [bug#73405: wrap-program should use the
>>> basename of $0 as arg0] does not describe why ‘cling’ was segfaulting,
>>> but I suspect it’s due to similar bad assumptions about argv[0] as the
>>> Emacs issue.
>>>
>>> I think wrappers should be as transparent as possible—however the user
>>> invokes a command should be preserved in argv[0], whether using a
>>> basename with PATH resolution or a relative or absolute filename. We
>>> shouldn’t coerce argv[0] to a basename when the wrapper wasn’t called
>>> that way. 99% of the time argv[0] is irrelevant, but the common case I’m
>>> considering is programs that log how they were called—it’s disorienting
>>> for the wrapper to affect that.
>>>
>>> Maybe we can expose an argument to wrap-program to use the basename
>>> approach, but IMO we should be handling the root cause in cases where
>>> problems occur and pushing upstreams to handle arbitrary argv[0] values
>>> robustly.
>>>
>>> WDYT? Thanks!
>>
>> This member of the peanut gallery supports the revert. Exactly as you
>> say, the wrappers should be as transparent as possible. So this
>> mangling feels wrong.
>
> After giving it some more thoughts, I agree. I think I had originally
> worked under the assumption that $0 would always expand to the absolute
> file name of the wrapper because of the wapper itself, but that's not
> the case; $0 exactly matches the way the user or launcher called the
> application, so it makes sense to preserve that information.
>
> It'll have to be done on the next core-packages branch though, as it's a
> world rebuild change.
There seems to be a `world-rebuild' branch now, which sounds like a good
fit?
Tomas
--
There are only two hard things in Computer Science:
cache invalidation, naming things and off-by-one errors.
Information forwarded
to
guix-patches <at> gnu.org
:
bug#73416
; Package
guix-patches
.
(Wed, 06 Aug 2025 21:18:02 GMT)
Full text and
rfc822 format available.
Message #32 received at 73416 <at> debbugs.gnu.org (full text, mbox):
Hello,
Am Wed, Aug 06, 2025 at 09:58:48PM +0200 schrieb Tomas Volf:
> There seems to be a `world-rebuild' branch now, which sounds like a good
> fit?
yes, I had suggested the branch, I just need a patch to add there.
Andreas
This bug report was last modified 3 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.