GNU bug report logs -
#40977
Tilde-expansion in --long-options=
Previous Next
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 40977 in the body.
You can then email your comments to 40977 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-guix <at> gnu.org:
bug#40977; Package
guix.
(Thu, 30 Apr 2020 08:17:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Hartmut Goebel <h.goebel <at> crazy-compilers.com>:
New bug report received and forwarded. Copy sent to
bug-guix <at> gnu.org.
(Thu, 30 Apr 2020 08:17:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
Specifying the home directory using `~` (tilde) in `--load-path` does
not add the proper path to
Does not work (not who "mypackage":
guix package --load-path=~/path/tp/my/project -A mypackage
Using $HOME (which si resolve by the shell works:
guix package --load-path=$HOME/path/tp/my/project -A mypackage
I would expect ~ and ~username to work, too.
Information forwarded
to
bug-guix <at> gnu.org:
bug#40977; Package
guix.
(Thu, 30 Apr 2020 15:33:02 GMT)
Full text and
rfc822 format available.
Message #8 received at 40977 <at> debbugs.gnu.org (full text, mbox):
Dear,
On Thu, 30 Apr 2020 at 10:17, Hartmut Goebel
<h.goebel <at> crazy-compilers.com> wrote:
>
> Specifying the home directory using `~` (tilde) in `--load-path` does
> not add the proper path to
>
> Does not work (not who "mypackage":
>
> guix package --load-path=~/path/tp/my/project -A mypackage
It seems related to long vs short options, not to the expansion.
The short option works:
guix package -L ~/path/to/my/project -A mypackage
but not the long '--load-path='.
> I would expect ~ and ~username to work, too.
Same for '~username'.
Well, I think it is related to bug #40549, see [1].
[1] https://debbugs.gnu.org/cgi/bugreport.cgi?bug=40549#14
All the best,
simon
Information forwarded
to
bug-guix <at> gnu.org:
bug#40977; Package
guix.
(Thu, 30 Apr 2020 16:39:01 GMT)
Full text and
rfc822 format available.
Message #11 received at 40977 <at> debbugs.gnu.org (full text, mbox):
On Thu, 30 Apr 2020 at 17:31, zimoun <zimon.toutoune <at> gmail.com> wrote:
>
> Dear,
>
> On Thu, 30 Apr 2020 at 10:17, Hartmut Goebel
> <h.goebel <at> crazy-compilers.com> wrote:
> >
> > Specifying the home directory using `~` (tilde) in `--load-path` does
> > not add the proper path to
> >
> > Does not work (not who "mypackage":
> >
> > guix package --load-path=~/path/tp/my/project -A mypackage
>
> It seems related to long vs short options, not to the expansion.
I am wrong. It is about the expansion. When using the short option,
then the expansion is done by the shell.
Note that it should be the same for '--manifest=~/path/to/manifests/'.
And all the '--long-options=~/path/to/something'.
Well, I do not find a function to expand tilde in Guile.
All the best,
simon
Information forwarded
to
bug-guix <at> gnu.org:
bug#40977; Package
guix.
(Thu, 30 Apr 2020 16:43:02 GMT)
Full text and
rfc822 format available.
Message #14 received at 40977 <at> debbugs.gnu.org (full text, mbox):
Hi,
This is not related to #40549.
The short option "-L ~/…" works, since thin this case the shell resolves the tilde. Whereas for the long-option the shell does not revolve the tilde, since the tilde is in the middle of the argument. Yu can verify this yourself easily:
$ python -c 'import sys; print(sys.argv)' ~
['-c', '/home/hartmut']
$ python -c 'import sys; print(sys.argv)' -L ~
['-c', '-L', '/home/hartmut']
$ python -c 'import sys; print(sys.argv)' ---long=~
['-c', '---long=~']
Proposed solution:
After processing options, guix need to "expanduser()" (as it is called
in Python) on all arguments which are paths.
--
Regards
Hartmut Goebel
| Hartmut Goebel | h.goebel <at> crazy-compilers.com |
| www.crazy-compilers.com | compilers which you thought are impossible |
Information forwarded
to
bug-guix <at> gnu.org:
bug#40977; Package
guix.
(Thu, 30 Apr 2020 16:51:01 GMT)
Full text and
rfc822 format available.
Message #17 received at 40977 <at> debbugs.gnu.org (full text, mbox):
Dear Hartmut,
On Thu, 30 Apr 2020 at 18:42, Hartmut Goebel
<h.goebel <at> crazy-compilers.com> wrote:
> The short option "-L ~/…" works, since thin this case the shell resolves the tilde. Whereas for the long-option the shell does not revolve the tilde, since the tilde is in the middle of the argument. Yu can verify this yourself easily:
Yes, you have right.
> Proposed solution:
>
> After processing options, guix need to "expanduser()" (as it is called
> in Python) on all arguments which are paths.
I agree.
I am not aware of such function in Guile.
All the best,
simon
Information forwarded
to
bug-guix <at> gnu.org:
bug#40977; Package
guix.
(Thu, 30 Apr 2020 17:35:01 GMT)
Full text and
rfc822 format available.
Message #20 received at 40977 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
> After processing options, guix need to "expanduser()" (as it is called
> in Python) on all arguments which are paths.
Please don't do it.
UNIX has its warts, and this is a well-known one (use ${HOME} instead).
If we did expanduser, I'm sure we'd be seeing bug reports about paths where
there was a tilde in the actual file name, NOT as a expanduser mark.
UNIX tools do what they do, and this wart is here to stay in a lot of tools.
Then at least make it consistent across all the tools UNIX has.
[Message part 2 (application/pgp-signature, inline)]
Information forwarded
to
bug-guix <at> gnu.org:
bug#40977; Package
guix.
(Thu, 30 Apr 2020 17:54:01 GMT)
Full text and
rfc822 format available.
Message #23 received at 40977 <at> debbugs.gnu.org (full text, mbox):
On Thu, Apr 30, 2020 at 07:34:39PM +0200, Danny Milosavljevic wrote:
> UNIX has its warts, and this is a well-known one (use ${HOME} instead).
>
> If we did expanduser, I'm sure we'd be seeing bug reports about paths where
> there was a tilde in the actual file name, NOT as a expanduser mark.
>
> UNIX tools do what they do, and this wart is here to stay in a lot of tools.
> Then at least make it consistent across all the tools UNIX has.
If it's true that this behaviour is more or less consistent in UNIX /
POSIX, then I agree with Danny that we should leave it as is. And, I
have noticed that ${HOME} is the way to go.
Information forwarded
to
bug-guix <at> gnu.org:
bug#40977; Package
guix.
(Thu, 30 Apr 2020 18:16:02 GMT)
Full text and
rfc822 format available.
Message #26 received at 40977 <at> debbugs.gnu.org (full text, mbox):
On Thu, 30 Apr 2020 at 19:53, Leo Famulari <leo <at> famulari.name> wrote:
> > UNIX tools do what they do, and this wart is here to stay in a lot of tools.
> > Then at least make it consistent across all the tools UNIX has.
I do not have a clear opinion on the subject so I fall with the
Danny's wise opinion.
Information forwarded
to
bug-guix <at> gnu.org:
bug#40977; Package
guix.
(Thu, 30 Apr 2020 19:21:01 GMT)
Full text and
rfc822 format available.
Message #29 received at 40977 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Hartmut, Zimoun,
Hartmut Goebel 写道：
> After processing options, guix need to "expanduser()" (as it is
> called
> in Python) on all arguments which are paths.
If any Python (or other) software does this, it's broken. File a
bug there.
This is the wrong thing to do and makes the GNU system an
inconsistent mess. …OK, *more* of an inconsistent, loveable, mess
;-)
It also makes
$ sudo guix system --load-path=~/path/tp/my/project …
and
$ sudo guix system -L ~/path/to/my/project -A mypackage …
suddenly result in different file names.
Please don't do it.
Kind regards,
T G-R
[signature.asc (application/pgp-signature, inline)]
Information forwarded
to
bug-guix <at> gnu.org:
bug#40977; Package
guix.
(Thu, 30 Apr 2020 20:56:01 GMT)
Full text and
rfc822 format available.
Message #32 received at 40977 <at> debbugs.gnu.org (full text, mbox):
Hi Tobias,
On Thu, 30 Apr 2020 at 21:20, Tobias Geerinckx-Rice <me <at> tobias.gr> wrote:
>
> Hartmut, Zimoun,
>
> Hartmut Goebel 写道：
> > After processing options, guix need to "expanduser()" (as it is
> > called
> > in Python) on all arguments which are paths.
>
> If any Python (or other) software does this, it's broken. File a
> bug there.
>
> This is the wrong thing to do and makes the GNU system an
> inconsistent mess. …OK, *more* of an inconsistent, loveable, mess
> ;-)
>
> It also makes
>
> $ sudo guix system --load-path=~/path/tp/my/project …
>
> and
>
> $ sudo guix system -L ~/path/to/my/project -A mypackage …
>
> suddenly result in different file names.
Sorry to be slow. Naive questions.
Do you mean the issue comes from who expand '~' (user vs sudo)?
Or do you mean refer to subfolder named '~, i.e., $HOME/foo/~/bar?
I should miss a point... about what is less or more inconsistent. :-)
Because it seems more based on conventions than on consistent inconsistencies.
About expansion, is it not the same question with
'--load-path=$HOME/path/to/' vs '-L $HOME/path/to/'?
About naming, is it possible to create a folder named '~' directly in $HOME?
Well, I am surely not enough skilled to have an opinion but I have
learnt something. :-)
> Please don't do it.
The fact that Guile does not have a built-in ``expand-tilde`` is a
strong indication to not do it. ;-)
Cheers,
simon
Information forwarded
to
bug-guix <at> gnu.org:
bug#40977; Package
guix.
(Fri, 01 May 2020 06:52:02 GMT)
Full text and
rfc822 format available.
Message #35 received at 40977 <at> debbugs.gnu.org (full text, mbox):
On +2020-04-30 22:54:47 +0200, zimoun wrote:
> Hi Tobias,
>
> On Thu, 30 Apr 2020 at 21:20, Tobias Geerinckx-Rice <me <at> tobias.gr> wrote:
> >
> > Hartmut, Zimoun,
> >
> > Hartmut Goebel 写道：
> > > After processing options, guix need to "expanduser()" (as it is
> > > called
> > > in Python) on all arguments which are paths.
> >
> > If any Python (or other) software does this, it's broken. File a
> > bug there.
> >
> > This is the wrong thing to do and makes the GNU system an
> > inconsistent mess. …OK, *more* of an inconsistent, loveable, mess
> > ;-)
> >
> > It also makes
> >
> > $ sudo guix system --load-path=~/path/tp/my/project …
> >
> > and
> >
> > $ sudo guix system -L ~/path/to/my/project -A mypackage …
> >
> > suddenly result in different file names.
>
> Sorry to be slow. Naive questions.
>
> Do you mean the issue comes from who expand '~' (user vs sudo)?
> Or do you mean refer to subfolder named '~, i.e., $HOME/foo/~/bar?
>
> I should miss a point... about what is less or more inconsistent. :-)
> Because it seems more based on conventions than on consistent inconsistencies.
>
> About expansion, is it not the same question with
> '--load-path=$HOME/path/to/' vs '-L $HOME/path/to/'?
> About naming, is it possible to create a folder named '~' directly in $HOME?
>
> Well, I am surely not enough skilled to have an opinion but I have
> learnt something. :-)
>
FYA:(Amusement): man bash to see what more ~ can lead to ;-)
(scroll down or search for the "Tilde Expansion" section)
>
> > Please don't do it.
>
> The fact that Guile does not have a built-in ``expand-tilde`` is a
> strong indication to not do it. ;-)
>
>
> Cheers,
> simon
>
>
>
--
Regards,
Bengt Richter
Information forwarded
to
bug-guix <at> gnu.org:
bug#40977; Package
guix.
(Fri, 01 May 2020 15:25:02 GMT)
Full text and
rfc822 format available.
Message #38 received at 40977 <at> debbugs.gnu.org (full text, mbox):
Dear,
Sorry to be slow.
On Thu, 30 Apr 2020 at 21:20, Tobias Geerinckx-Rice <me <at> tobias.gr> wrote:
> Hartmut Goebel 写道：
> This is the wrong thing to do and makes the GNU system an
> inconsistent mess. …OK, *more* of an inconsistent, loveable, mess
> ;-)
I still think that the behaviour of Guix could be considered as a bug
and inconsistent with other GNU tools, such as Emacs -- to pick one
but Emacs should be an exception in the GNU tools landscape
(inconsistent loveable mess :-))
Maybe what I am saying is irrelevant and only bikeshedding.
Like Saint-Thomas, I only believe that I see. ;-)
> It also makes
>
> $ sudo guix system --load-path=~/path/tp/my/project …
>
> and
>
> $ sudo guix system -L ~/path/to/my/project -A mypackage …
>
> suddenly result in different file names.
Emacs behaves differently; and it is what is expected (at least by me :-)).
--8<---------------cut here---------------start------------->8---
mkdir -p ${HOME}/tmp/foo
cat <<EOF > ${HOME}/tmp/foo/eg.el
(defun an-example ()
(interactive)
(message (car load-path))
(message (expand-file-name "kikoo" "~/foo/~/bar")))
(provide 'eg)
EOF
# ~ means /home/simon/
sudo emacs --batch -L ~/tmp/foo/ --eval "(require 'eg)" --eval "(an-example)"
# ~ mean /root/
sudo emacs --batch --directory=~/tmp/foo/ --eval "(require 'eg)"
--eval "(an-example)"
--8<---------------cut here---------------end--------------->8---
The first '~' is expanded by the shell so in the user's context. The
second '~' is expanded by Emacs so in the root's context.
Well, nothing new. :-)
This is not the issue, if I understand correctly.
This issue is about the subfolders named '~'.
--8<---------------cut here---------------start------------->8---
mkdir -p ${HOME}/tmp/foo/~/bar
cat <<EOF > ${HOME}/tmp/foo/~/bar/ex.el
(defun from-tilde ()
(interactive)
(message (car load-path))
(message (expand-file-name "yahoga" "~/foo/~/bar")))
(provide 'ex)
EOF
cd ${HOME}/tmp/foo
# ~ means /home/simon
emacs --batch --directory=~/bar/ --eval "(require 'ex)" --eval "(from-tilde)"
# protect ~
emacs --batch --directory=./~/bar/ --eval "(require 'ex)" --eval "(from-tilde)"
--8<---------------cut here---------------end--------------->8---
From the folder '${HOME}/foo', Emacs is run with prepending the
subfolder named '~'. The first line fails because the folder
'/home/simon/bar/' does not exist. The second '~' refers to the
correct subfolder because of the dot.
Now the behaviour of Emacs is inconsistent with the Guix's behaviour.
--8<---------------cut here---------------start------------->8---
cd ${HOME}/foo
guix show --load-path=~/bar from-tilde
--8<---------------cut here---------------end--------------->8---
This works. Because Guix uses the argument as it is. Note that
'--load-path=./~/bar/' works too.
And note that from the folder '$HOME/tmp/foo', the commands
guix show -L ~/bar from-tilde
and
guix show --load-path=~/bar from-tilde
refer to different file names. And it appears to me weirder than the
tilde expansion done as Emacs does.
--8<---------------cut here---------------s tart------------->8---
mkdir -p ${HOME}/tmp/foo/~/bar
cat <<EOF > ${HOME}/tmp/foo/~/bar/from-tilde.scm
(define-module (from-tilde)
#:use-module (guix packages)
#:use-module (gnu packages maths))
(pk (car %load-path))
(define-public from-tilde
(package
(inherit gmsh)
(name "from-tilde")))
EOF
--8<---------------cut here---------------end--------------->8---
> Please don't do it.
Well, in summary.
I have no knowledge about GNU tools and how they expand '~'.
I agree that '~' could be considered as a wart. And I do not know if
considering '~' as shortcut for $HOME is a "good practise" or not.
But I use '~' as meaning $HOME more more often than I create an
obscure subfolder named '~' (well I never did :-)). And I treat with
care the filename when I use 'sudo' because it is context switch so so
error-prone.
Maybe wrong terminology has been used with 'expanduser' but Guix
should expand '~' in agreement with the GNU Bash tilde-expansion
section IMHO.
(And this is valid for any '--long-option=~'.)
Therefore does the "it" in the Danny's and Tobias's "don't do it" mean
tilde-expansion?
Sorry again to be slow or bikeshed.
Best regards,
simon
Information forwarded
to
bug-guix <at> gnu.org:
bug#40977; Package
guix.
(Sat, 02 May 2020 13:15:02 GMT)
Full text and
rfc822 format available.
Message #41 received at 40977 <at> debbugs.gnu.org (full text, mbox):
Danny Milosavljevic <dannym <at> scratchpost.org> skribis:
>> After processing options, guix need to "expanduser()" (as it is called
>> in Python) on all arguments which are paths.
>
> Please don't do it.
>
> UNIX has its warts, and this is a well-known one (use ${HOME} instead).
Seconded.
Tilde expansion is performed by the shell. In the case of
‘--foo=~/bar’, tilde expansion does not happen because ~ is right in the
middle of a string.
It’s admittedly annoying, but it’s not something Guix itself should
paper over. Doing that would open a can of worms, as illustrated by the
example Tobias gave.
Ludo’.
Added tag(s) notabug.
Request was from
Ludovic Courtès <ludo <at> gnu.org>
to
control <at> debbugs.gnu.org.
(Sat, 02 May 2020 13:15:02 GMT)
Full text and
rfc822 format available.
bug closed, send any further explanations to
40977 <at> debbugs.gnu.org and Hartmut Goebel <h.goebel <at> crazy-compilers.com>
Request was from
Ludovic Courtès <ludo <at> gnu.org>
to
control <at> debbugs.gnu.org.
(Sat, 02 May 2020 13:15:03 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-guix <at> gnu.org:
bug#40977; Package
guix.
(Sat, 02 May 2020 13:56:01 GMT)
Full text and
rfc822 format available.
Message #48 received at 40977 <at> debbugs.gnu.org (full text, mbox):
On Sat, 2 May 2020 at 15:14, Ludovic Courtès <ludo <at> gnu.org> wrote:
> It’s admittedly annoying, but it’s not something Guix itself should
> paper over. Doing that would open a can of worms, as illustrated by the
> example Tobias gave.
Instead of 'notabug' , I propose to tag this bug as 'wontfix' and
retitle it as: "Tilde-expansion in --long-options=".
Is it ok?
Best regards,
simon
ps:
Quoting the 'wontfix' explanation [1]: ``this is a choice between two
arbitrary ways of doing things and the maintainer and submitter prefer
different ways of doing things``.
[1] https://debbugs.gnu.org/Developer.html#tags
Information forwarded
to
bug-guix <at> gnu.org:
bug#40977; Package
guix.
(Sat, 02 May 2020 22:15:01 GMT)
Full text and
rfc822 format available.
Message #51 received at 40977 <at> debbugs.gnu.org (full text, mbox):
zimoun <zimon.toutoune <at> gmail.com> skribis:
> On Sat, 2 May 2020 at 15:14, Ludovic Courtès <ludo <at> gnu.org> wrote:
>
>> It’s admittedly annoying, but it’s not something Guix itself should
>> paper over. Doing that would open a can of worms, as illustrated by the
>> example Tobias gave.
>
> Instead of 'notabug' , I propose to tag this bug as 'wontfix' and
> retitle it as: "Tilde-expansion in --long-options=".
>
> Is it ok?
Sure.
Ludo’.
Removed tag(s) notabug.
Request was from
zimoun <zimon.toutoune <at> gmail.com>
to
control <at> debbugs.gnu.org.
(Sun, 03 May 2020 15:20:02 GMT)
Full text and
rfc822 format available.
Added tag(s) wontfix.
Request was from
zimoun <zimon.toutoune <at> gmail.com>
to
control <at> debbugs.gnu.org.
(Sun, 03 May 2020 15:20:02 GMT)
Full text and
rfc822 format available.
Changed bug title to 'Tilde-expansion in --long-options=' from '--load-path does not honor ~'
Request was from
zimoun <zimon.toutoune <at> gmail.com>
to
control <at> debbugs.gnu.org.
(Sun, 03 May 2020 15:20:02 GMT)
Full text and
rfc822 format available.
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org.
(Mon, 01 Jun 2020 11:24:07 GMT)
Full text and
rfc822 format available.
This bug report was last modified 5 years and 24 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.