From: zimoun <zimon.toutoune@gmail.com>
To: Tobias Geerinckx-Rice <me@tobias.gr>,
Danny Milosavljevic <dannym@scratchpost.org>,
Leo Famulari <leo@famulari.name>, Bengt Richter <bokr@bokr.com>
Cc: 40977@debbugs.gnu.org
Subject: bug#40977: --load-path does not honor ~
Date: Fri, 1 May 2020 17:24:18 +0200 [thread overview]
Message-ID: <CAJ3okZ03nmo-JABJ-YNs9YLpBm2Hr_YWX9hns8KCENS2aMpehQ@mail.gmail.com> (raw)
In-Reply-To: <87y2qcsst3.fsf@nckx>
Dear,
Sorry to be slow.
On Thu, 30 Apr 2020 at 21:20, Tobias Geerinckx-Rice <me@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
prev parent reply other threads:[~2020-05-01 15:26 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-04-30 8:15 bug#40977: --load-path does not honor ~ Hartmut Goebel
2020-04-30 15:31 ` zimoun
2020-04-30 16:37 ` zimoun
2020-04-30 16:42 ` Hartmut Goebel
2020-04-30 16:50 ` zimoun
2020-04-30 17:34 ` Danny Milosavljevic
2020-04-30 17:53 ` Leo Famulari
2020-04-30 18:14 ` zimoun
2020-05-02 13:14 ` Ludovic Courtès
2020-05-02 13:55 ` zimoun
2020-05-02 22:14 ` Ludovic Courtès
2020-04-30 19:21 ` Tobias Geerinckx-Rice via Bug reports for GNU Guix
2020-04-30 20:54 ` zimoun
2020-05-01 6:51 ` Bengt Richter
2020-05-01 15:24 ` zimoun [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://guix.gnu.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAJ3okZ03nmo-JABJ-YNs9YLpBm2Hr_YWX9hns8KCENS2aMpehQ@mail.gmail.com \
--to=zimon.toutoune@gmail.com \
--cc=40977@debbugs.gnu.org \
--cc=bokr@bokr.com \
--cc=dannym@scratchpost.org \
--cc=leo@famulari.name \
--cc=me@tobias.gr \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/guix.git
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).