* [UX] real names exposed
@ 2016-08-31 18:25 Troy Sankey
2016-08-31 23:11 ` Leo Famulari
0 siblings, 1 reply; 11+ messages in thread
From: Troy Sankey @ 2016-08-31 18:25 UTC (permalink / raw)
To: help-guix
[-- 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-----
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [UX] real names exposed
2016-08-31 18:25 [UX] real names exposed Troy Sankey
@ 2016-08-31 23:11 ` Leo Famulari
2016-08-31 23:33 ` Eric Bavier
0 siblings, 1 reply; 11+ messages in thread
From: Leo Famulari @ 2016-08-31 23:11 UTC (permalink / raw)
To: Troy Sankey; +Cc: help-guix
[-- 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 --]
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [UX] real names exposed
2016-08-31 23:11 ` Leo Famulari
@ 2016-08-31 23:33 ` Eric Bavier
2016-09-01 8:59 ` Ludovic Courtès
0 siblings, 1 reply; 11+ messages in thread
From: Eric Bavier @ 2016-08-31 23:33 UTC (permalink / raw)
To: Leo Famulari; +Cc: help-guix, Help-Guix
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
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [UX] real names exposed
2016-08-31 23:33 ` Eric Bavier
@ 2016-09-01 8:59 ` Ludovic Courtès
2016-09-03 15:30 ` Troy Sankey
2016-09-03 22:33 ` Ludovic Courtès
0 siblings, 2 replies; 11+ messages in thread
From: Ludovic Courtès @ 2016-09-01 8:59 UTC (permalink / raw)
To: Eric Bavier; +Cc: Help-Guix, help-guix
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’.
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [UX] real names exposed
2016-09-01 8:59 ` Ludovic Courtès
@ 2016-09-03 15:30 ` Troy Sankey
2016-09-03 22:21 ` Troy Sankey
2016-09-03 22:33 ` Ludovic Courtès
1 sibling, 1 reply; 11+ messages in thread
From: Troy Sankey @ 2016-09-03 15:30 UTC (permalink / raw)
To: Ludovic Courtès, Eric Bavier; +Cc: help-guix, Help-Guix
[-- 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-----
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [UX] real names exposed
2016-09-03 15:30 ` Troy Sankey
@ 2016-09-03 22:21 ` Troy Sankey
2016-09-04 19:38 ` Ludovic Courtès
0 siblings, 1 reply; 11+ messages in thread
From: Troy Sankey @ 2016-09-03 22:21 UTC (permalink / raw)
To: Ludovic Courtès, Eric Bavier; +Cc: help-guix, Help-Guix
[-- 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-----
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [UX] real names exposed
2016-09-01 8:59 ` Ludovic Courtès
2016-09-03 15:30 ` Troy Sankey
@ 2016-09-03 22:33 ` Ludovic Courtès
2016-09-04 19:41 ` Ludovic Courtès
1 sibling, 1 reply; 11+ messages in thread
From: Ludovic Courtès @ 2016-09-03 22:33 UTC (permalink / raw)
To: Eric Bavier; +Cc: help-guix, Help-Guix
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’.
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [UX] real names exposed
2016-09-03 22:33 ` Ludovic Courtès
@ 2016-09-04 19:41 ` Ludovic Courtès
2016-09-06 3:09 ` Eric Bavier
0 siblings, 1 reply; 11+ messages in thread
From: Ludovic Courtès @ 2016-09-04 19:41 UTC (permalink / raw)
To: Eric Bavier; +Cc: help-guix, Help-Guix
[-- 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
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [UX] real names exposed
2016-09-04 19:41 ` Ludovic Courtès
@ 2016-09-06 3:09 ` Eric Bavier
2016-09-07 22:04 ` Ludovic Courtès
0 siblings, 1 reply; 11+ messages in thread
From: Eric Bavier @ 2016-09-06 3:09 UTC (permalink / raw)
To: Ludovic Courtès; +Cc: help-guix, Help-Guix
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
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [UX] real names exposed
2016-09-06 3:09 ` Eric Bavier
@ 2016-09-07 22:04 ` Ludovic Courtès
0 siblings, 0 replies; 11+ messages in thread
From: Ludovic Courtès @ 2016-09-07 22:04 UTC (permalink / raw)
To: Eric Bavier; +Cc: help-guix, Help-Guix
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’.
^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2016-09-07 22:05 UTC | newest]
Thread overview: 11+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2016-08-31 18:25 [UX] real names exposed Troy Sankey
2016-08-31 23:11 ` Leo Famulari
2016-08-31 23:33 ` Eric Bavier
2016-09-01 8:59 ` Ludovic Courtès
2016-09-03 15:30 ` Troy Sankey
2016-09-03 22:21 ` Troy Sankey
2016-09-04 19:38 ` Ludovic Courtès
2016-09-03 22:33 ` Ludovic Courtès
2016-09-04 19:41 ` Ludovic Courtès
2016-09-06 3:09 ` Eric Bavier
2016-09-07 22:04 ` Ludovic Courtès
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).