|
From: | GNU bug Tracking System |
Subject: | [debbugs-tracker] bug#28156: closed (Emacs quietly munges symlink contents) |
Date: | Sun, 27 Aug 2017 01:54:02 +0000 |
Your message dated Sat, 26 Aug 2017 18:53:25 -0700 with message-id <address@hidden> and subject line Re: bug#28156: Emacs quietly munges symlink contents has caused the debbugs.gnu.org bug report #28156, regarding Emacs quietly munges symlink contents to be marked as done. (If you believe you have received this mail in error, please contact address@hidden) -- 28156: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=28156 GNU Bug Tracking System Contact address@hidden with problems
--- Begin Message ---Subject: Emacs quietly munges symlink contents Date: Sun, 20 Aug 2017 03:28:04 -0700 User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 Tags: patchThe 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.It strikes me that a similar change probably needs to be made to Tramp, so that remote symlinks also can be arbitrary strings too. However, that's outside my expertise so this patch affects only local symlink contents.0001-Do-not-munge-contents-of-local-symbolic-links.patch
Description: Text Data
--- End Message ---
--- Begin Message ---Subject: Re: bug#28156: Emacs quietly munges symlink contents Date: Sat, 26 Aug 2017 18:53:25 -0700 User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 Michael Albinus wrote:What about file-truename? I believe it still must quote the result, otherwise we run into problems. See (make-symbolic-link "/x:y:" "/tmp/foo") (file-truename "/tmp/foo") The latter shall return "/:/x:y:" (as of today) instead of "/x:y:".Thanks for catching that. While looking into it, I noticed that file-truename has long mishandled symlink contents starting with ~ as in the following example:$ ln -s '~nosuchuser' /tmp/foo $ ls -l /tmp/foo lrwxrwxrwx. 1 eggert eggert 11 Aug 26 18:51 /tmp/foo -> ~nosuchuser $ src/emacs -Q -batch -eval '(message "%S" (file-truename "/tmp/foo"))' "/home/eggert/src/gnu/emacs/master-tmp/~nosuchuser" I fixed both problems.Yes, the documentation could stand some improving here. I fixed it up a bit, though not in the file-truename area as I'm thinking we may need some more changes here and would like to cogitate about it first. I'll CC: you on any further bug reports in this area.Maybe we shall document it as well. Neither the docstring of `file-truename', nor the Lisp reference say something about.I rebased the patch to master which simplified it since I no longer had to worry about Tramp tests, and installed the result. Closing this bug report.
--- End Message ---
[Prev in Thread] | Current Thread | [Next in Thread] |