GNU bug report logs - #73416
[PATCH core-updates] build: Set $0 to basename of command in `wrap-program'.

Previous Next

Package: guix-patches;

Reported by: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>

Date: Sun, 22 Sep 2024 06:08:01 UTC

Severity: normal

Tags: patch

Done: Ludovic Courtès <ludo <at> gnu.org>

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.

View this report as an mbox folder, status mbox, maintainer mbox


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

From: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
To: guix-patches <at> gnu.org
Cc: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
Subject: [PATCH core-updates] build: Set $0 to basename of command in
 `wrap-program'.
Date: Sun, 22 Sep 2024 15:06:18 +0900
* 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):

From: Ludovic Courtès <ludo <at> gnu.org>
To: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
Cc: 73416-done <at> debbugs.gnu.org, Andreas Enge <andreas <at> enge.fr>,
 73405-done <at> debbugs.gnu.org
Subject: Re: bug#73416: [PATCH core-updates] build: Set $0 to basename of
 command in `wrap-program'.
Date: Sat, 22 Mar 2025 23:35:28 +0100
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):

From: Liam Hupfer <liam <at> hpfr.net>
To: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>, 73416 <at> debbugs.gnu.org
Cc: Andreas Enge <andreas <at> enge.fr>,
 Ludovic Courtès <ludo <at> gnu.org>,
 Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
Subject: Re: [bug#73416] [PATCH core-updates] build: Set $0 to basename of
 command in `wrap-program'.
Date: Sat, 19 Jul 2025 21:54:43 -0500
[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):

From: Liam Hupfer <liam <at> hpfr.net>
To: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>, 73416 <at> debbugs.gnu.org
Cc: Andreas Enge <andreas <at> enge.fr>,
 Ludovic Courtès <ludo <at> gnu.org>,
 Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
Subject: Re: [bug#73416] [PATCH core-updates] build: Set $0 to basename of
 command in `wrap-program'.
Date: Mon, 21 Jul 2025 00:24:18 -0500
[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):

From: Tomas Volf <~@wolfsden.cz>
To: Liam Hupfer <liam <at> hpfr.net>
Cc: 73416 <at> debbugs.gnu.org, Andreas Enge <andreas <at> enge.fr>,
 Ludovic Courtès <ludo <at> gnu.org>,
 Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
Subject: Re: [bug#73416] [PATCH core-updates] build: Set $0 to basename of
 command in `wrap-program'.
Date: Mon, 21 Jul 2025 14:02:22 +0200
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):

From: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
To: Tomas Volf <~@wolfsden.cz>
Cc: 73416 <at> debbugs.gnu.org, Andreas Enge <andreas <at> enge.fr>,
 Liam Hupfer <liam <at> hpfr.net>, Ludovic Courtès <ludo <at> gnu.org>
Subject: Re: [bug#73416] [PATCH core-updates] build: Set $0 to basename of
 command in `wrap-program'.
Date: Wed, 23 Jul 2025 10:28:42 +0900
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):

From: Tomas Volf <~@wolfsden.cz>
To: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
Cc: 73416 <at> debbugs.gnu.org, Andreas Enge <andreas <at> enge.fr>,
 Liam Hupfer <liam <at> hpfr.net>, Ludovic Courtès <ludo <at> gnu.org>
Subject: Re: [bug#73416] [PATCH core-updates] build: Set $0 to basename of
 command in `wrap-program'.
Date: Wed, 06 Aug 2025 21:58:48 +0200
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):

From: Andreas Enge <andreas <at> enge.fr>
To: Tomas Volf <~@wolfsden.cz>
Cc: 73416 <at> debbugs.gnu.org, Ludovic Courtès <ludo <at> gnu.org>,
 Liam Hupfer <liam <at> hpfr.net>, Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
Subject: Re: [bug#73416] [PATCH core-updates] build: Set $0 to basename of
 command in `wrap-program'.
Date: Wed, 6 Aug 2025 23:17:14 +0200
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.