GNU bug report logs -
#28156
Emacs quietly munges symlink contents
Previous Next
Reported by: Paul Eggert <eggert <at> cs.ucla.edu>
Date: Sun, 20 Aug 2017 10:29:01 UTC
Severity: normal
Tags: patch
Done: Paul Eggert <eggert <at> cs.ucla.edu>
Bug is archived. No further changes may be made.
Full log
View this message in rfc822 format
On 08/22/2017 12:28 AM, Michael Albinus wrote:
> If you want to have an absolute filename as LINKNAME, you typically call
>
> (make-symbolic-link (expand-file-name target) (expand-file-name linkname))
>
> In case of remote file names, (expand-file-name linkname) will always
> return something like "/method:user <at> host:/path/to/linkname". I doubt,
> that a user wants to see this literal string as symbolic link.
There seems to be some confusion here, as Bug#28156 does not propose any
change to how make-symbolic-link's 2nd argument works, (expand-file-name
linkname) in this case. If the 2nd argument specifies a remote name, as
in your example, then Tramp will take over and do whatever it wants with
both arguments, so Bug#28156 is not proposing any change there (although
perhaps some changes would be helpful for consistency, that's a
different matter).
Bug#28156 is proposing changes only when the new linkname is local, and
in those cases, if I'm not mistaken, Emacs currently errors out when the
target looks like it is remote, so Bug#28156 is merely proposing an
extension. Emacs routinely creates dangling symlinks with targets
containing unusual characters like ":", and it wouldn't be surprising if
users wanted to do something similar on their own.
> Furthermore, there is the OK-IF-ALREADY-EXISTS argument of
> make-symbolic-string. This requires to regard LINKNAME as a file name,
> and not as a literal string.
That's fine, as Bug#28156 is not proposing any change here. LINKNAME
continues to be treated as a file name under the proposed change. The
proposed change affects only symlink contents, not symlink names.
This bug report was last modified 7 years and 269 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.