From mboxrd@z Thu Jan 1 00:00:00 1970 From: ludo@gnu.org (Ludovic =?utf-8?Q?Court=C3=A8s?=) Subject: Re: [UX] real names exposed Date: Thu, 01 Sep 2016 10:59:02 +0200 Message-ID: <87wpiwt2qx.fsf@gnu.org> References: <147266794967.23966.13712862947716543821@what> <20160831231110.GB18814@jasmine> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:49778) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bfNq5-0007WP-Kz for help-guix@gnu.org; Thu, 01 Sep 2016 04:59:14 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bfNq3-0008F5-MY for help-guix@gnu.org; Thu, 01 Sep 2016 04:59:12 -0400 In-Reply-To: (Eric Bavier's message of "Wed, 31 Aug 2016 18:33:53 -0500") List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: help-guix-bounces+gcggh-help-guix=m.gmane.org@gnu.org Sender: "Help-Guix" To: Eric Bavier Cc: Help-Guix , help-guix@gnu.org Eric Bavier skribis: > On 2016-08-31 18:11, Leo Famulari wrote: >> On Wed, Aug 31, 2016 at 02:25:49PM -0400, Troy Sankey wrote: >>> I understand why this happens: >>> >>> % khal --help >>> Usage: .khal-real [OPTIONS] COMMAND [ARGS]... >>> [...] >>> >>> but I think it sorta sucks for user experience. Just thought I'd >>> point this >>> out, and I was wondering if there were any ideas to address this. >>> >>> Specifically, argv[0] references the name of the "real" executable, >>> rather than >>> the guix wrapper. This is almost always benign, but it looks ugly >>> in help >>> menus. >> >> I wonder if the Khal author (Christian) intends for users to rename the >> executable. Otherwise, why use argv[0]? Is it some side-effect of a >> documentation tool used by Khal? >> >> I would understand if khal and ikhal were the same executable, and >> behavior was changed based on argv[0], but that's not the case. >> >> It does look ugly. > > It's not just khal. Most other executables and scripts that reference > argv[0] or $0 end up with the *=3Dreal string. > > In our wrapper scripts, we pass -a to exec, which is supposed to > address this issue, but for some reason it seems ineffective. =E2=80=98exec -a=E2=80=99 works as advertised: --8<---------------cut here---------------start------------->8--- $ sh -c 'exec -a FOO guile -c "(pk (command-line))"' ;;; (("FOO")) --8<---------------cut here---------------end--------------->8--- Yet: --8<---------------cut here---------------start------------->8--- $ sh -c 'exec -a FOO /gnu/store/6vmniz83k46l8jpry50wdvwxsncz1r5w-khal-0.7.0= /bin/.khal-wrap-01 --version' .khal-real, version 0.7.0 --8<---------------cut here---------------end--------------->8--- And in fact: --8<---------------cut here---------------start------------->8--- $ cat > t.py import sys print(sys.argv[0]) $ sh -c 'exec -a FOO python3 t.py' t.py --8<---------------cut here---------------end--------------->8--- =E2=80=A6 even though argv[0] is initially correct: --8<---------------cut here---------------start------------->8--- $ sh -c 'exec -a FOO python3 --help' | head -1 usage: FOO [option] ... [-c cmd | -m mod | file | -] [arg] ... --8<---------------cut here---------------end--------------->8--- So somewhere, Python finds out the real name, but it doesn=E2=80=99t seem t= o be via /proc/cmdline or anything like that, and I couldn=E2=80=99t find the ex= act hack in the source. Ideas? I would really like to fix it in =E2=80=98core-updates=E2=80=99. Ludo=E2=80=99.