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 22:16:04 +0300 Message-ID: <83bmnacaob.fsf@gnu.org> References: <68b2e6ef-bf0b-ebcf-c577-d296952d593f@cs.ucla.edu> <83pobqcnlf.fsf@gnu.org> <83h8x2ckqn.fsf@gnu.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: blaine.gmane.org X-Trace: blaine.gmane.org 1503256636 9051 195.159.176.226 (20 Aug 2017 19:17:16 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 20 Aug 2017 19:17:16 +0000 (UTC) Cc: p.stephani2@gmail.com, 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 21:17:09 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 1djVid-0001td-Bp for geb-bug-gnu-emacs@m.gmane.org; Sun, 20 Aug 2017 21:17:07 +0200 Original-Received: from localhost ([::1]:50778 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1djVii-0001Rj-GI for geb-bug-gnu-emacs@m.gmane.org; Sun, 20 Aug 2017 15:17:12 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:56919) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1djViZ-0001R5-EX for bug-gnu-emacs@gnu.org; Sun, 20 Aug 2017 15:17:04 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1djViY-0007DV-CT for bug-gnu-emacs@gnu.org; Sun, 20 Aug 2017 15:17:03 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:38237) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1djViY-0007DR-9C for bug-gnu-emacs@gnu.org; Sun, 20 Aug 2017 15:17:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1djViY-0004Xv-4a for bug-gnu-emacs@gnu.org; Sun, 20 Aug 2017 15:17:02 -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 19:17:02 +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.150325661817463 (code B ref 28156); Sun, 20 Aug 2017 19:17:02 +0000 Original-Received: (at 28156) by debbugs.gnu.org; 20 Aug 2017 19:16:58 +0000 Original-Received: from localhost ([127.0.0.1]:46918 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1djViU-0004Xb-9W for submit@debbugs.gnu.org; Sun, 20 Aug 2017 15:16:58 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:37669) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1djViR-0004XN-UE for 28156@debbugs.gnu.org; Sun, 20 Aug 2017 15:16:56 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1djViJ-0007Au-Gk for 28156@debbugs.gnu.org; Sun, 20 Aug 2017 15:16:50 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:43665) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1djViJ-0007Ao-D3; Sun, 20 Aug 2017 15:16:47 -0400 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:4392 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1djViF-0002DE-Nm; Sun, 20 Aug 2017 15:16:47 -0400 In-reply-to: (message from Paul Eggert on Sun, 20 Aug 2017 10:54:45 -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:135954 Archived-At: > Cc: michael.albinus@gmx.de, 28156@debbugs.gnu.org > From: Paul Eggert > Date: Sun, 20 Aug 2017 10:54:45 -0700 > > > We have quoting for these cases. > > Quoting does not work for these cases. If I try to rename a symlink to the > literal string '~eggert' on my machine, Emacs will misbehave as described and > there is no way to quote the string naming the symlink to fix this. That is but one use case of many. In other cases, quoting does work. > > doesn't Emacs behave here like Unix shell commands do? > > They differ in many ways. Two examples. First, the Unix shell command 'ln -s > ~/$$ def' expands both the "~" and the "$$", whereas (make-symbolic-link "~/$$" > "def") expands only the "~". Second, the Unix shell command "ln -s def" creates > a symlink to itself, whereas (make-symbolic-link "def") is an error. Briefly, > the Unix shell commands are higher-level than the Emacs primitives. I never said that Emacs does everything the shell does, and does it exactly like the shell. I was only talking about "~" expansion, so let's not muddy the waters by adding more magic characters and expansions into what is already a tricky issue. > The main points here are (1) Emacs functions should let users create and > manipulate whatever symlinks they want to, and (2) the documentation has long > said that symlinks are not expanded. I agree. But I think your proposed changes will disallow some of the users' capabilities to do what you want. What's more, they seem to sacrifice a very common interactive use case on behalf of a much more rare and obscure one. I'm talking about a user typing this: M-x make-symbolic-link RET ~/foo/bar RET /toto/quux RET AFAIU, with your changes the "~" in the first file name will not be expanded. If I'm right, then you will disallow using "~" as the short for the home directory in this case, which IMO is unacceptable, as Emacs allows this in any other interactive command that accepts file names. At the very least, we should preserve the current ability of the user to specify "~" shorthands in interactive invocations of make-symbolic-link. If you want to allow users to specify a literal "~" in this scenario, I agree, but it seems like we already allow that; see Micheal's example. > > 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 > > Yes, they will fail unless there is a directory named '~'. That is the intent. > If I want to create a symlink to my home directory, I can use expand-file-name > on the link target, before calling make-symbolic-link. We cannot force users call expand-file-name in interactive use of these commands. It's simply unacceptable. I don't even know how users could do that in practice -- do you expect them to type TAB or something? How can this work?