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>

Full log


View this message in rfc822 format

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




This bug report was last modified today.

Previous Next


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