bug#28156: Emacs quietly munges symlink contents

[Eli Zaretskii]

> From: Paul Eggert <eggert@cs.ucla.edu>
> Date: Sun, 20 Aug 2017 03:28:04 -0700
> Cc: Michael Albinus <michael.albinus@gmx.de>
> 
> The attached patch fixes some Emacs behavior that disagrees with the 
> documentation.  Although the user manual says that make-symbolic-link "does
> not expand the argument TARGET", Emacs expands leading "~" in the target. 
> Also, 
> file-symlink-p quietly munges symlink contents if they appear to be a Tramp 
> file 
> name. This behavior makes it impossible to write Emacs code that deals with 
> arbitrary local symbolic links, and Emacs mishandles copying of some symlinks 
> for this reason. At the operating system level, symlink targets are merely 
> strings, and are not file names that are interpreted (any interpretation 
> occurs 
> later, only when the symlinks are followed), and Emacs should be consistent 
> with 
> that.

Sorry, I'm probably missing something here, but doesn't Emacs behave
here like Unix shell commands do?  For example, I just did

  $ ln -s ~/bin/etags ttt

and the following 'ls' command shows this:

  $ ls -l ttt
  lrwxrwxrwx 1 eliz eliz 22 Aug 20 10:27 ttt -> /home/e/eliz/bin/etags*

AFAIU, this means the shell expanded "~" when it passed it to 'ln'.
And Emacs tries to behave like the shell does in this case (and in
other similar cases).  Why is that wrong?

Moreover, unless I again misunderstand something important, 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, because AFAIK most programs don't
expand "~" (with the notable exception of the shell).

What am I missing here?

>  +++
> +** 'file-attributes', 'file-symlink-p' and 'make-symbolic-link' no
> +longer quietly mutate the target of a local symbolic link.  In
> +particular, 'file-attributes' and 'file-symlink-p' no longer prepend
> +"/:" to some targets of local symbolic links, and 'make-symbolic-link'
> +no longer expands '~' at the start of a link target.  This change lets
> +Emacs access and copy arbitrary local symbolic links.

Regardless of the issue at hand, if the change is installed, this text
should be clarified.  As written, I find it very hard to understand
what is the nature of the change, and how does it change the old
behavior.  For example, the reference to "some targets" could benefit
from a couple of examples showing the old and the new behavior in each
case.

Thanks.