|
From: | Paul Eggert |
Subject: | bug#28156: Emacs quietly munges symlink contents |
Date: | Tue, 22 Aug 2017 09:03:52 -0700 |
User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 |
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@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.
[Prev in Thread] | Current Thread | [Next in Thread] |