From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#28156: Emacs quietly munges symlink contents Date: Sun, 20 Aug 2017 17:37:00 +0300 Message-ID: <83pobqcnlf.fsf@gnu.org> References: <68b2e6ef-bf0b-ebcf-c577-d296952d593f@cs.ucla.edu> Reply-To: Eli Zaretskii NNTP-Posting-Host: blaine.gmane.org X-Trace: blaine.gmane.org 1503239903 9524 195.159.176.226 (20 Aug 2017 14:38:23 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 20 Aug 2017 14:38:23 +0000 (UTC) Cc: michael.albinus@gmx.de, 28156@debbugs.gnu.org To: Paul Eggert Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sun Aug 20 16:38:17 2017 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1djRMe-0001qF-Mg for geb-bug-gnu-emacs@m.gmane.org; Sun, 20 Aug 2017 16:38:08 +0200 Original-Received: from localhost ([::1]:54888 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1djRMl-0007YM-EG for geb-bug-gnu-emacs@m.gmane.org; Sun, 20 Aug 2017 10:38:15 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:44721) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1djRMb-0007WJ-7V for bug-gnu-emacs@gnu.org; Sun, 20 Aug 2017 10:38:06 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1djRMY-0007su-4i for bug-gnu-emacs@gnu.org; Sun, 20 Aug 2017 10:38:05 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:38091) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1djRMY-0007sm-1J for bug-gnu-emacs@gnu.org; Sun, 20 Aug 2017 10:38:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1djRMX-0006aF-RX for bug-gnu-emacs@gnu.org; Sun, 20 Aug 2017 10:38:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 20 Aug 2017 14:38:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 28156 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch Original-Received: via spool by 28156-submit@debbugs.gnu.org id=B28156.150323984125261 (code B ref 28156); Sun, 20 Aug 2017 14:38:01 +0000 Original-Received: (at 28156) by debbugs.gnu.org; 20 Aug 2017 14:37:21 +0000 Original-Received: from localhost ([127.0.0.1]:46772 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1djRLt-0006ZN-9k for submit@debbugs.gnu.org; Sun, 20 Aug 2017 10:37:21 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:53704) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1djRLr-0006Z9-Qq for 28156@debbugs.gnu.org; Sun, 20 Aug 2017 10:37:20 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1djRLl-0007cH-BX for 28156@debbugs.gnu.org; Sun, 20 Aug 2017 10:37:14 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:41599) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1djRLg-0007aM-Gp; Sun, 20 Aug 2017 10:37:08 -0400 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:4140 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1djRLf-0007b9-Rn; Sun, 20 Aug 2017 10:37:08 -0400 In-reply-to: <68b2e6ef-bf0b-ebcf-c577-d296952d593f@cs.ucla.edu> (message from Paul Eggert on Sun, 20 Aug 2017 03:28:04 -0700) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 208.118.235.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:135939 Archived-At: > From: Paul Eggert > Date: Sun, 20 Aug 2017 03:28:04 -0700 > Cc: Michael Albinus > > 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? 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? > +++ > +** 'file-attributes', 'file-symlink-p' and 'make-symbolic-link' no > +longer quietly mutate the target of a local symbolic link. In > +particular, 'file-attributes' and 'file-symlink-p' no longer prepend > +"/:" to some targets of local symbolic links, and 'make-symbolic-link' > +no longer expands '~' at the start of a link target. This change lets > +Emacs access and copy arbitrary local symbolic links. Regardless of the issue at hand, if the change is installed, this text should be clarified. As written, I find it very hard to understand what is the nature of the change, and how does it change the old behavior. For example, the reference to "some targets" could benefit from a couple of examples showing the old and the new behavior in each case. Thanks.