GNU bug report logs - #28156
Emacs quietly munges symlink contents

Previous Next

Full log

View this message in rfc822 format

From: Philipp Stephani <p.stephani2 <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>, Paul Eggert <eggert <at> cs.ucla.edu>
Cc: michael.albinus <at> gmx.de, 28156 <at> debbugs.gnu.org
Subject: bug#28156: Emacs quietly munges symlink contents
Date: Sun, 20 Aug 2017 15:09:01 +0000

[Message part 1 (text/plain, inline)]

Eli Zaretskii <eliz <at> gnu.org> schrieb am So., 20. Aug. 2017 um 16:38 Uhr:

> > From: Paul Eggert <eggert <at> cs.ucla.edu>
> > Date: Sun, 20 Aug 2017 03:28:04 -0700
> > Cc: Michael Albinus <michael.albinus <at> 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.

[Message part 2 (text/html, inline)]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.