bug#28156: Emacs quietly munges symlink contents

[Eli Zaretskii]

> 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?