bug#40977: --load-path does not honor ~
zimoun skribis: > On Sat, 2 May 2020 at 15:14, Ludovic Courtès 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’.
bug#40977: --load-path does not honor ~
On Sat, 2 May 2020 at 15:14, Ludovic Courtès 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
bug#40977: --load-path does not honor ~
Danny Milosavljevic 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’.
bug#40977: --load-path does not honor ~
Dear,
Sorry to be slow.
On Thu, 30 Apr 2020 at 21:20, Tobias Geerinckx-Rice 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 < ${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 < ${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 < ${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
bug#40977: --load-path does not honor ~
On +2020-04-30 22:54:47 +0200, zimoun wrote: > Hi Tobias, > > On Thu, 30 Apr 2020 at 21:20, Tobias Geerinckx-Rice 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
bug#40977: --load-path does not honor ~
Hi Tobias, On Thu, 30 Apr 2020 at 21:20, Tobias Geerinckx-Rice 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
bug#40977: --load-path does not honor ~
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 Description: PGP signature
bug#40977: --load-path does not honor ~
On Thu, 30 Apr 2020 at 19:53, Leo Famulari 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.
bug#40977: --load-path does not honor ~
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.
bug#40977: --load-path does not honor ~
Dear Hartmut, On Thu, 30 Apr 2020 at 18:42, Hartmut Goebel 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
bug#40977: --load-path does not honor ~
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.goe...@crazy-compilers.com | | www.crazy-compilers.com | compilers which you thought are impossible |
bug#40977: --load-path does not honor ~
Dear, On Thu, 30 Apr 2020 at 10:17, Hartmut Goebel 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
