[UX] real names exposed

[UX] real names exposed

[Troy Sankey]

[-- Attachment #1: Type: text/plain, Size: 431 bytes --]

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.

Troy

[-- Attachment #2: signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAABCAAGBQJXxyEpAAoJEIRGmXXw0dCUjQAP/i4TYMAz6oTsyzvWtu8X6Uat
HE1GpWorMztwaZGH4uihQs/pIiQiorfSbQt+Git66z/X1hBl55Srz5gMYHgumZ4B
wA7mm8lIkXvOS/mx+ClzAgeP4w180lM1KHj6ftvH8Zhe+XSCGgwq63oSS/1jS0aW
8c9umRsn+RwwsJ1jXmRdUuTDX0bT7m3xwGSGYU1vAXLk++x7wQ6id4bVjF8lLmvE
Lp6hVbijRimUuYB6qxs3YHZp+rZ+XZH8KxZ0D4MUb9DCnSeBOsN4TXFZ5zX4uiFX
WRPtUrRdMYhuoG/luzJZC+hsbtZdxstQZLqfoL1G7Cy8aRJwYfn/uvoVv1+m2LZ0
p9nLlCU1VON6OzpUeOPmJXwaI1UZmLn9XzUeuk4jTm6iSAT+WZnfGr+4b/0mUD2d
0vdotwODFAhGcaqSAsIjuChK+wThqrbRlPOkes89dIBK40GbBhKRJP4ftSN3N+Ve
0UTI8wrwY+yWC3/0twSg9mwpq86Kxkzddj91lYd781lQOEVR9qTi1Sv+yAcjeJfv
zhCcXND4D0a192VxDkDM7S0tvWL2IZIzf7bYD10x2EIMURBIUYdXsffcsL9U6EBB
OX+y9rA+zkF6d5teeBGF9lsTvtZROL5LgVcIE+zP6Qo7DD3fDSvs1CypMCoiG56R
eg8KeKoa1CX1jh21rI1b
=QiB1
-----END PGP SIGNATURE-----

Re: [UX] real names exposed

[Leo Famulari]

[-- Attachment #1: Type: text/plain, Size: 844 bytes --]

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.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [UX] real names exposed

[Eric Bavier]

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 *=real string.

In our wrapper scripts, we pass -a to exec, which is supposed to address 
this issue, but for some reason it seems ineffective.

`~Eric
-- 
`~Eric

Re: [UX] real names exposed

[Ludovic Courtès]

Eric Bavier <ericbavier@openmailbox.org> 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 *=real string.
>
> In our wrapper scripts, we pass -a to exec, which is supposed to
> address this issue, but for some reason it seems ineffective.

‘exec -a’ 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---

… 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’t seem to be
via /proc/cmdline or anything like that, and I couldn’t find the exact
hack in the source.

Ideas?

I would really like to fix it in ‘core-updates’.

Ludo’.

Re: [UX] real names exposed

[Troy Sankey]

[-- Attachment #1: Type: text/plain, Size: 1976 bytes --]

Quoting Ludovic Courtès (2016-09-01 04:59:02)
> ‘exec -a’ works as advertised:
> 
> --8<---------------cut here---------------start------------->8---
> $ sh -c 'exec -a FOO guile -c "(pk (command-line))"'
> 
> ;;; (("FOO"))
> --8<---------------cut here---------------end--------------->8---

So, here /proc/self/cmdline would be: guile\0
and bash changed it to: FOO\0

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

here it's: python3\0.khal-real\0--version\0
bash changed it to: FOO\0.khal-real\0--version\0

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

here it's: python3\0t.py\0
bash changed it to: FOO\0t.py\0

> … 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’t seem to be
> via /proc/cmdline or anything like that, and I couldn’t find the exact
> hack in the source.
>
> Ideas?

Seems that there is no reason to think python doesn't simply use
/proc/self/cmdline.  Before script interpretation, but after spawning,
the python interpreter appears to modify the arguments list to hide the
first element:

  argv = argv[1:]  # I made this up, but it's probably something like this

> I would really like to fix it in ‘core-updates’.
> 
> Ludo’.

[-- Attachment #2: signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAABCAAGBQJXyuyHAAoJEIRGmXXw0dCUTPoP/AwtT9EbEt+4ksuXZ+0p3ECs
7NQSfgyAuA2FihJExuC3OlVjYhi8+Ncb/LKXbEmC7rF0S6bIs2CS6Eqrv5Rbjl5S
heMmXXbErXv8kt1UB9ngTaOE7DKhcLn2SxGt/d5spZYStun1Z6y4Q5eUJN2YOXqG
oXXd5xayLo//YeRmwzjOAaiKPkuF9nVpicZzhEMj21Z05vfWilAlKlgp3q0Dbp9m
ggNjfoCwek4pt9NvJubZdWIuzvUdmYRcYonKWYWEiFqjApdwSXQHQhoANRLdOq4T
hsWyT0aRDjsWHUMpa85K4qNTOGCakDb2dbEs+VyS9duAwRbW2euufyeJF2SrqXLh
xijYzbLfaXLJxv/AwBGu4/qP6OS5Tb6VVzMu4/4khSOzoEKEumiPrYdQc7UA476Q
mmJjs8hTowzlEkn5OGHHwbqIFaZG63x1VmUVVKYKwNa5DpvPagHrwnasHAyzQ2RZ
NA9mWj7w7lzly0xDxkfj33WhECqyKgY/JrPl+sSw4pXO6kiX7COu0jvJVxkswGhM
6VauHWjiJhHdoTSGPNWsHQbEFKlZlCK/GzdJ4+2XTTHDUYp6krkOolSvwsDGFQds
/FT+6AwWMvwkdvba9nLfRsz039tunV3TYVLltLBGDr4S1eFrt/hpLfarfpt3dtK0
hcV5NnyZDOVgc279a15W
=gMuy
-----END PGP SIGNATURE-----

Re: [UX] real names exposed

[Troy Sankey]

[-- Attachment #1: Type: text/plain, Size: 1029 bytes --]

I suspect the scope of this UX "bug" is larger than python.  I think this probably affects every executable written in an interpreted
language and using a shebang.  Here's another example with a bash
script:

  $ cat > t.sh
  #!/bin/bash
  sed 's/\x0/\\0/g'  # replaces null bytes with a visible '\0'
  
  $ ./t.sh </proc/self/cmdline
  /bin/bash\0./t.sh\0

Looks like '/bin/bash' is argv[0].  What happens when we try exec -a:
  
  $ bash -c 'exec -a FOO bash t.sh </proc/self/cmdline'
  FOO\0t.sh\0

  $ bash -c 'exec -a FOO ./t.sh </proc/self/cmdline'
  /bin/bash\0/tmp/t.sh\0

"t.sh" still appears. The result of that last command surprised me,
there's no FOO in /prod/self/cmdline at all (still confused)!  By the
way, bash does the same as python, in that $0 always references the
script name, never the actual argv[0]:

  $ cat >s.sh
  #!/bin/bash
  echo $0
  
  $ ./s.sh </proc/self/cmdline
  ./s.sh

  $ bash s.sh </proc/self/cmdline
  s.sh

I'm not sure what the solution is.

Troy

[-- Attachment #2: signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAABCAAGBQJXy0zRAAoJEIRGmXXw0dCUIM4P/3VL2lx7UaXaj3KvSi3tkS8q
Xx88KQwuxrMWGWHN36PbH1LNxlsh6051L0/cgYu9WDmuHhTDlkYjFcLhydeXOpM8
6z6bD3WYuYQPPTG/59RW94DfzZZ0JeVQMllkfOhk+Lx/fuR0cnyVsE12I3X5SBFe
b9kn7HEZiHAF9GXW4UflWraty4rwCXbJIxCpNkBv3YEC+B3GHTyQoU/sRm3sY9zG
V/y7gmGToe4FJfh7xSGx9Zw9Sz5ngqdhOYxF/o9wggu4YbUXbR50Vflsr8ffj29N
zZZcBV0rJ6IAj/0hbPTHeY76anfnSBuSYUrpIA1c6u5PtFcsEZE7pKRu473qHAZa
4QqvDdQwg9vNSYw6L8i9XCs2dTUleFJhZB4O8JKSQgCGsaKINId47TeVcP1z8aDt
tacC5Rb1r/uk4+k9hm4XzDjNKkey3uX617k7H5KdTzyiT3skapd0r2oNt56h5SVJ
/gVwDj/sfP24/khYuUtlU8Mz7+wx98ZhLUB/TSAIALBGvVFnkfZB7qgplB09gKcH
6bfqhdDGj3VzccfOWHScLv/TbciCFkCOJC+drtjx/LZ32jBT7rBV27mVL+vfDcCV
D0no+sich3/wk8K0eNsIx7b+dqpPqVPaH5lV7Gq7Qzh85XvJ5z9QY+IQEQu+VRPz
RhE1lsxW0cPHK/zPkyTQ
=Z5Wl
-----END PGP SIGNATURE-----

Re: [UX] real names exposed

[Ludovic Courtès]

Troy Sankey <sankeytms@gmail.com> skribis:

> I suspect the scope of this UX "bug" is larger than python.  I think this probably affects every executable written in an interpreted
> language and using a shebang.

Exactly, that’s also the conclusion that I reached.  :-/

Ludo’.

Re: [UX] real names exposed

[Ludovic Courtès]

Hello,

ludo@gnu.org (Ludovic Courtès) skribis:

> $ sh -c 'exec -a FOO /gnu/store/6vmniz83k46l8jpry50wdvwxsncz1r5w-khal-0.7.0/bin/.khal-wrap-01  --version'
> .khal-real, version 0.7.0

What happens is that ‘exec -a’ is doesn’t work when the wrapped program
is a script.

This is because, when invoked via a shebang (or when passed the file
name of a script), interpreters receive the file name of the script as
argv[1], and then typically shift argv to the left (argv[1] becomes
argv[0] etc.)

AFAICS there’s no generic solution to this problem.  :-/

Ludo’.

Re: [UX] real names exposed

[Ludovic Courtès]

[-- Attachment #1: Type: text/plain, Size: 255 bytes --]

While playing with ‘wrap-program’, I rewrote it so create a single
wrapper and modify that wrapper when it exists instead of layering an
extra wrapper.

Thoughts?  If there are no objections, I’d like to commit this one.

Thanks,
Ludo’.


[-- Attachment #2: Type: text/x-patch, Size: 5217 bytes --]

modified   guix/build/utils.scm
@@ -1,5 +1,5 @@
 ;;; GNU Guix --- Functional package management for GNU
-;;; Copyright © 2012, 2013, 2014, 2015 Ludovic Courtès <ludo@gnu.org>
+;;; Copyright © 2012, 2013, 2014, 2015, 2016 Ludovic Courtès <ludo@gnu.org>
 ;;; Copyright © 2013 Andreas Enge <andreas@enge.fr>
 ;;; Copyright © 2013 Nikita Karetnikov <nikita@karetnikov.org>
 ;;; Copyright © 2015 Mark H Weaver <mhw@netris.org>
@@ -946,62 +946,68 @@ modules in $GUILE_LOAD_PATH, etc.
 
 If PROG has previously been wrapped by wrap-program the wrapper will point to
 the previous wrapper."
-  (define (wrapper-file-name number)
-    (format #f "~a/.~a-wrap-~2'0d" (dirname prog) (basename prog) number))
-  (define (next-wrapper-number)
-    (let ((wrappers
-           (find-files (dirname prog)
-                       (string-append "\\." (basename prog) "-wrap-.*"))))
-      (if (null? wrappers)
-          0
-          (string->number (string-take-right (last wrappers) 2)))))
-  (define (wrapper-target number)
-    (if (zero? number)
-        (let ((prog-real (string-append (dirname prog) "/."
-                                        (basename prog) "-real")))
-          (rename-file prog prog-real)
-          prog-real)
-        (wrapper-file-name number)))
+  (define wrapped-file
+    (string-append (dirname prog) "/." (basename prog) "-real"))
 
-  (let* ((number   (next-wrapper-number))
-         (target   (wrapper-target number))
-         (wrapper  (wrapper-file-name (1+ number)))
-         (prog-tmp (string-append target "-tmp")))
-    (define (export-variable lst)
-      ;; Return a string that exports an environment variable.
-      (match lst
-        ((var sep '= rest)
-         (format #f "export ~a=\"~a\""
-                 var (string-join rest sep)))
-        ((var sep 'prefix rest)
-         (format #f "export ~a=\"~a${~a~a+~a}$~a\""
-                 var (string-join rest sep) var sep sep var))
-        ((var sep 'suffix rest)
-         (format #f "export ~a=\"$~a${~a~a+~a}~a\""
-                 var var var sep sep (string-join rest sep)))
-        ((var '= rest)
-         (format #f "export ~a=\"~a\""
-                 var (string-join rest ":")))
-        ((var 'prefix rest)
-         (format #f "export ~a=\"~a${~a:+:}$~a\""
-                 var (string-join rest ":") var var))
-        ((var 'suffix rest)
-         (format #f "export ~a=\"$~a${~a:+:}~a\""
-                 var var var (string-join rest ":")))))
+  (define already-wrapped?
+    (file-exists? wrapped-file))
 
-    (with-output-to-file prog-tmp
-      (lambda ()
-        (format #t
-                "#!~a~%~a~%exec -a \"$0\" \"~a\" \"$@\"~%"
-                (which "bash")
-                (string-join (map export-variable vars)
-                             "\n")
-                (canonicalize-path target))))
+  (define (last-line port)
+    (let loop ((previous-line-offset 0)
+               (previous-line "")
+               (position (seek port 0 SEEK_CUR)))
+      (match (read-line port 'concat)
+        ((? eof-object?)
+         (seek port previous-line-offset SEEK_SET)
+         previous-line)
+        ((? string? line)
+         (loop position line (+ (string-length line) position))))))
 
-    (chmod prog-tmp #o755)
-    (rename-file prog-tmp wrapper)
-    (symlink wrapper prog-tmp)
-    (rename-file prog-tmp prog)))
+  (define (export-variable lst)
+    ;; Return a string that exports an environment variable.
+    (match lst
+      ((var sep '= rest)
+       (format #f "export ~a=\"~a\""
+               var (string-join rest sep)))
+      ((var sep 'prefix rest)
+       (format #f "export ~a=\"~a${~a~a+~a}$~a\""
+               var (string-join rest sep) var sep sep var))
+      ((var sep 'suffix rest)
+       (format #f "export ~a=\"$~a${~a~a+~a}~a\""
+               var var var sep sep (string-join rest sep)))
+      ((var '= rest)
+       (format #f "export ~a=\"~a\""
+               var (string-join rest ":")))
+      ((var 'prefix rest)
+       (format #f "export ~a=\"~a${~a:+:}$~a\""
+               var (string-join rest ":") var var))
+      ((var 'suffix rest)
+       (format #f "export ~a=\"$~a${~a:+:}~a\""
+               var var var (string-join rest ":")))))
+
+  (if already-wrapped?
+      (let* ((port (open-file prog "r+"))
+             (last (last-line port)))
+        (for-each (lambda (var)
+                    (display (export-variable var) port)
+                    (newline port))
+                  vars)
+        (display last port)
+        (close-port port))
+      (let ((prog-tmp (string-append wrapped-file "-tmp")))
+        (copy-file prog wrapped-file)
+
+        (call-with-output-file prog-tmp
+          (lambda (port)
+            (format port
+                    "#!~a --~%~a~%exec -a \"$0\" \"~a\" \"$@\"~%"
+                    (which "bash")
+                    (string-join (map export-variable vars)
+                                 "\n")
+                    (canonicalize-path wrapped-file))))
+
+        (chmod prog-tmp #o755)
+        (rename-file prog-tmp prog))))
 
 \f

Re: [UX] real names exposed

[Eric Bavier]

On Sun, 04 Sep 2016 21:41:01 +0200
ludo@gnu.org (Ludovic Courtès) wrote:

> While playing with ‘wrap-program’, I rewrote it so create a single
> wrapper and modify that wrapper when it exists instead of layering an
> extra wrapper.
> 
> Thoughts?  If there are no objections, I’d like to commit this one.

Seems reasonable to me.

`~Eric

Re: [UX] real names exposed

[Ludovic Courtès]

Eric Bavier <ericbavier@openmailbox.org> skribis:

> On Sun, 04 Sep 2016 21:41:01 +0200
> ludo@gnu.org (Ludovic Courtès) wrote:
>
>> While playing with ‘wrap-program’, I rewrote it so create a single
>> wrapper and modify that wrapper when it exists instead of layering an
>> extra wrapper.
>> 
>> Thoughts?  If there are no objections, I’d like to commit this one.
>
> Seems reasonable to me.

Pushed as b14a8385095f6672960fb8378c6578acf1ebbf8a.

Ludo’.