From: Eli Zaretskii <eliz@gnu.org>
To: Paul Eggert <eggert@cs.ucla.edu>
Cc: p.stephani2@gmail.com, michael.albinus@gmx.de, 28156@debbugs.gnu.org
Subject: bug#28156: Emacs quietly munges symlink contents
Date: Sun, 20 Aug 2017 22:16:04 +0300 [thread overview]
Message-ID: <83bmnacaob.fsf@gnu.org> (raw)
In-Reply-To: <ad3ce8d9-608b-b382-7591-0777408edc09@cs.ucla.edu> (message from Paul Eggert on Sun, 20 Aug 2017 10:54:45 -0700)
> Cc: michael.albinus@gmx.de, 28156@debbugs.gnu.org
> From: Paul Eggert <eggert@cs.ucla.edu>
> Date: Sun, 20 Aug 2017 10:54:45 -0700
>
> > We have quoting for these cases.
>
> Quoting does not work for these cases. If I try to rename a symlink to the
> literal string '~eggert' on my machine, Emacs will misbehave as described and
> there is no way to quote the string naming the symlink to fix this.
That is but one use case of many. In other cases, quoting does work.
> > doesn't Emacs behave here like Unix shell commands do?
>
> They differ in many ways. Two examples. First, the Unix shell command 'ln -s
> ~/$$ def' expands both the "~" and the "$$", whereas (make-symbolic-link "~/$$"
> "def") expands only the "~". Second, the Unix shell command "ln -s def" creates
> a symlink to itself, whereas (make-symbolic-link "def") is an error. Briefly,
> the Unix shell commands are higher-level than the Emacs primitives.
I never said that Emacs does everything the shell does, and does it
exactly like the shell. I was only talking about "~" expansion, so
let's not muddy the waters by adding more magic characters and
expansions into what is already a tricky issue.
> The main points here are (1) Emacs functions should let users create and
> manipulate whatever symlinks they want to, and (2) the documentation has long
> said that symlinks are not expanded.
I agree. But I think your proposed changes will disallow some of the
users' capabilities to do what you want. What's more, they seem to
sacrifice a very common interactive use case on behalf of a much more
rare and obscure one. I'm talking about a user typing this:
M-x make-symbolic-link RET ~/foo/bar RET /toto/quux RET
AFAIU, with your changes the "~" in the first file name will not be
expanded. If I'm right, then you will disallow using "~" as the short
for the home directory in this case, which IMO is unacceptable, as
Emacs allows this in any other interactive command that accepts file
names.
At the very least, we should preserve the current ability of the user
to specify "~" shorthands in interactive invocations of
make-symbolic-link. If you want to allow users to specify a literal
"~" in this scenario, I agree, but it seems like we already allow
that; see Micheal's example.
> > If make-symbolic-link would create a link like this:
> >
> > ttt -> ~/bin/etags
> >
> > (which is what your proposed change does, right?), then programs which
> > follow the link will probably fail
>
> Yes, they will fail unless there is a directory named '~'. That is the intent.
> If I want to create a symlink to my home directory, I can use expand-file-name
> on the link target, before calling make-symbolic-link.
We cannot force users call expand-file-name in interactive use of
these commands. It's simply unacceptable. I don't even know how
users could do that in practice -- do you expect them to type TAB or
something? How can this work?
next prev parent reply other threads:[~2017-08-20 19:16 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-08-20 10:28 bug#28156: Emacs quietly munges symlink contents Paul Eggert
2017-08-20 13:48 ` Michael Albinus
2017-08-20 14:37 ` Eli Zaretskii
2017-08-20 15:09 ` Philipp Stephani
2017-08-20 15:38 ` Eli Zaretskii
2017-08-20 17:54 ` Paul Eggert
2017-08-20 18:28 ` Michael Albinus
2017-08-20 18:53 ` Paul Eggert
2017-08-20 19:15 ` Michael Albinus
2017-08-20 21:47 ` Paul Eggert
2017-08-21 7:36 ` Michael Albinus
2017-08-20 19:21 ` Eli Zaretskii
2017-08-20 21:31 ` Paul Eggert
2017-08-21 2:34 ` Eli Zaretskii
2017-08-21 8:34 ` Paul Eggert
2017-08-21 14:25 ` Eli Zaretskii
2017-08-21 15:58 ` Paul Eggert
2017-08-20 19:16 ` Eli Zaretskii [this message]
2017-08-21 17:34 ` Paul Eggert
2017-08-21 17:59 ` Eli Zaretskii
2017-08-21 20:30 ` Paul Eggert
2017-08-22 7:28 ` Michael Albinus
2017-08-22 16:03 ` Paul Eggert
2017-08-24 11:38 ` Michael Albinus
2017-08-25 5:12 ` Paul Eggert
2017-08-25 12:45 ` Michael Albinus
2017-08-26 13:16 ` Michael Albinus
2017-08-27 1:53 ` Paul Eggert
2017-08-20 22:19 ` npostavs
2017-08-20 23:00 ` Paul Eggert
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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=83bmnacaob.fsf@gnu.org \
--to=eliz@gnu.org \
--cc=28156@debbugs.gnu.org \
--cc=eggert@cs.ucla.edu \
--cc=michael.albinus@gmx.de \
--cc=p.stephani2@gmail.com \
/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 external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.