From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Philipp Stephani Newsgroups: gmane.emacs.bugs Subject: bug#28156: Emacs quietly munges symlink contents Date: Sun, 20 Aug 2017 15:09:01 +0000 Message-ID: References: <68b2e6ef-bf0b-ebcf-c577-d296952d593f@cs.ucla.edu> <83pobqcnlf.fsf@gnu.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="001a113d32ac9bbdc3055730beaa" X-Trace: blaine.gmane.org 1503241814 13071 195.159.176.226 (20 Aug 2017 15:10:14 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 20 Aug 2017 15:10:14 +0000 (UTC) Cc: michael.albinus@gmx.de, 28156@debbugs.gnu.org To: Eli Zaretskii , Paul Eggert Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sun Aug 20 17:10: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 1djRra-0002rZ-AH for geb-bug-gnu-emacs@m.gmane.org; Sun, 20 Aug 2017 17:10:06 +0200 Original-Received: from localhost ([::1]:57648 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1djRrf-000431-B5 for geb-bug-gnu-emacs@m.gmane.org; Sun, 20 Aug 2017 11:10:11 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:48085) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1djRrZ-000425-68 for bug-gnu-emacs@gnu.org; Sun, 20 Aug 2017 11:10:06 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1djRrV-0006kO-VP for bug-gnu-emacs@gnu.org; Sun, 20 Aug 2017 11:10:05 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:38138) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1djRrV-0006kG-S4 for bug-gnu-emacs@gnu.org; Sun, 20 Aug 2017 11:10:01 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1djRrV-0007LN-Id for bug-gnu-emacs@gnu.org; Sun, 20 Aug 2017 11:10:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Philipp Stephani Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 20 Aug 2017 15:10: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.150324175828176 (code B ref 28156); Sun, 20 Aug 2017 15:10:01 +0000 Original-Received: (at 28156) by debbugs.gnu.org; 20 Aug 2017 15:09:18 +0000 Original-Received: from localhost ([127.0.0.1]:46819 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1djRqo-0007KO-7y for submit@debbugs.gnu.org; Sun, 20 Aug 2017 11:09:18 -0400 Original-Received: from mail-oi0-f42.google.com ([209.85.218.42]:34800) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1djRqn-0007KC-5Q for 28156@debbugs.gnu.org; Sun, 20 Aug 2017 11:09:17 -0400 Original-Received: by mail-oi0-f42.google.com with SMTP id j144so6290658oib.1 for <28156@debbugs.gnu.org>; Sun, 20 Aug 2017 08:09:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=o5fy+sjEqqfv9JApk7nOHoqA/ceMbWjEYRIpXsGx4Wg=; b=cPXB/ay0T0+g3nk+xqnnZJPORLnrFv+uTPyb/C6eNVF/sYffh2uCzLcEhVNu3/L6I8 9atmkg6bGYKS6b+USLE9nTeSIBj3z3hj2S3iurD2YvFc4LrezuScNuB607nzt9ZmJimH JLggV8wABSEUOD/mS27qFR6483shSSiCZL6c3yNvJgJLLTeUm0y/u/OSwadz4PyN9bvE p1FdeuO7lp+i/07aIDYwbu1WZd/oyYGyWYWAIdbNtiDsLHPH0h+1WCpblGcdPnR7lD5C ZCbuL3SJmpzJUV3ieELAYabZuImcrt4AAc+Z1LaEHGWgALaHBOEjNJHRORjxk6VVf+0w X5jQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=o5fy+sjEqqfv9JApk7nOHoqA/ceMbWjEYRIpXsGx4Wg=; b=GY1SxvXPbIRNlfc/apCR/wSVEoL6uTJDZTJi1wSUKv9JyXvm1IMyDaJ7y46HRrBvpG aJaNse4o2GqXuGnf9ipyiwVhNJhK9Hcw9Y5vzhum24EqbrazvgqR3ciKqaapT1JIbsMg mOYucKJs6Kh2dSNmGy4Ue8cecvshRbtuvWOQVW/9T19b/h+BDv5vIqiI/TFR1H/ExS51 uMffUmOkPOquf0mmbllpJ/c6a4DsKC5epmdYOcjMhJFy7ad8NK4TSDL4TZqdzIOTZoY1 p88AqVVKDw1J6bXpfCaRLClT2A4jfT/m9qWWoFrA0m/n07BGw32ktapQfRXxYWtvENX1 DY8w== X-Gm-Message-State: AHYfb5jW0hLq+kf7dKdNFjZn0CNuXiyRikU7A2bQx6U6VWf5pIhwmNAf FEq8Zr4uHOswmxjxV3BD5P1F65jRUA== X-Received: by 10.202.194.139 with SMTP id s133mr18794331oif.222.1503241751476; Sun, 20 Aug 2017 08:09:11 -0700 (PDT) In-Reply-To: <83pobqcnlf.fsf@gnu.org> 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:135945 Archived-At: --001a113d32ac9bbdc3055730beaa Content-Type: text/plain; charset="UTF-8" Eli Zaretskii schrieb am So., 20. Aug. 2017 um 16:38 Uhr: > > 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? > It makes it impossible to use '~' as a directory name. Higher-level interactive interfaces such as Shell and Dired can live with such a restriction, but library APIs need to be able to work with arbitrary inputs. > > 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? Callers of `make-symbolic-link' will need to expand the target themselves. --001a113d32ac9bbdc3055730beaa Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


Eli Za= retskii <eliz@gnu.org> schrieb am= So., 20. Aug. 2017 um 16:38=C2=A0Uhr:
> From: Paul Eggert <eggert@cs.ucla.edu>
> Date: Sun, 20 Aug 2017 03:28:04 -0700
> Cc: Michael Albinus <michael.albinus@gmx.de>
>
> The attached patch fixes some Emacs behavior that disagrees with the > documentation.=C2=A0 Although the user manual says that make-symbolic-= link "does
> not expand the argument TARGET", Emacs expands leading "~&qu= ot; 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 s= ymlinks
> for this reason. At the operating system level, symlink targets are me= rely
> strings, and are not file names that are interpreted (any interpretati= on occurs
> later, only when the symlinks are followed), and Emacs should be consi= stent with
> that.

Sorry, I'm probably missing something here, but doesn't Emacs behav= e
here like Unix shell commands do?=C2=A0 For example, I just did

=C2=A0 $ ln -s ~/bin/etags ttt

and the following 'ls' command shows this:

=C2=A0 $ ls -l ttt
=C2=A0 lrwxrwxrwx 1 eliz eliz 22 Aug 20 10:27 ttt -> /home/e/eliz/bin/et= ags*

AFAIU, this means the shell expanded "~" when it passed it to = 9;ln'.
And Emacs tries to behave like the shell does in this case (and in
other similar cases).=C2=A0 Why is that wrong?

It makes it impossible to use '~' as a directory name. High= er-level interactive interfaces such as Shell and Dired can live with such = a restriction, but library APIs need to be able to work with arbitrary inpu= ts.
=C2=A0

Moreover, unless I again misunderstand something important, if
make-symbolic-link would create a link like this:

=C2=A0 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?

Callers of `make-sy= mbolic-link' will need to expand the target themselves.=C2=A0
--001a113d32ac9bbdc3055730beaa--