Eli Zaretskii <
eliz@gnu.org> schrieb am So., 20. Aug. 2017 um 16:38 Uhr:
> 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?
It makes it impossible to use '~' as a directory name. Higher-level interactive interfaces such as Shell and Dired can live with such a restriction, but library APIs need to be able to work with arbitrary inputs.
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?
Callers of `make-symbolic-link' will need to expand the target themselves.