From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: kai.grossjohann@uni-duisburg.de (Kai =?iso-8859-1?q?Gro=DFjohann?=) Newsgroups: gmane.emacs.devel Subject: Re: file-relative-name and remote files Date: Fri, 21 Mar 2003 15:20:33 +0100 Organization: University of Duisburg, Germany Sender: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Message-ID: <84bs04u7gu.fsf@lucy.is.informatik.uni-duisburg.de> References: <3E5A8D95.9090803@math.ku.dk> <3E5C8BAC.8000201@math.ku.dk> <3E5E1F42.3020705@math.ku.dk> <84heaex5cc.fsf@lucy.is.informatik.uni-duisburg.de> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: main.gmane.org 1048256600 6078 80.91.224.249 (21 Mar 2003 14:23:20 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Fri, 21 Mar 2003 14:23:20 +0000 (UTC) Original-X-From: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Fri Mar 21 15:23:19 2003 Return-path: Original-Received: from quimby.gnus.org ([80.91.224.244]) by main.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 18wNQV-0001Zh-00 for ; Fri, 21 Mar 2003 15:23:19 +0100 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.12 #1 (Debian)) id 18wNSG-0000xJ-00 for ; Fri, 21 Mar 2003 15:25:08 +0100 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.10.13) id 18wNPz-0006ZZ-02 for emacs-devel@quimby.gnus.org; Fri, 21 Mar 2003 09:22:47 -0500 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.10.13) id 18wNPK-0005p3-00 for emacs-devel@gnu.org; Fri, 21 Mar 2003 09:22:06 -0500 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.10.13) id 18wNPD-0005Pe-00 for emacs-devel@gnu.org; Fri, 21 Mar 2003 09:22:00 -0500 Original-Received: from main.gmane.org ([80.91.224.249]) by monty-python.gnu.org with esmtp (Exim 4.10.13) id 18wNOx-0004pk-00 for emacs-devel@gnu.org; Fri, 21 Mar 2003 09:21:43 -0500 Original-Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 18wNOQ-0001PB-00 for ; Fri, 21 Mar 2003 15:21:10 +0100 X-Injected-Via-Gmane: http://gmane.org/ Original-To: emacs-devel@gnu.org Original-Received: from news by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 18wNO4-0001Ns-00 for ; Fri, 21 Mar 2003 15:20:48 +0100 Original-Lines: 49 Original-X-Complaints-To: usenet@main.gmane.org User-Agent: Gnus/5.090016 (Oort Gnus v0.16) Emacs/21.3.50 (gnu/linux) Cancel-Lock: sha1:PmnZ8v1Ybk9UG8ZfBMIxgqp5ZkY= X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1b5 Precedence: list List-Id: Emacs development discussions. List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , Errors-To: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Xref: main.gmane.org gmane.emacs.devel:12506 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:12506 Richard Stallman writes: > Kai Grossjohann writes: > >> But Richard wants to allow ".." to cross file handler boundaries. >> So "/foo:/../bar" should expand to "/bar", just like "/foo/../bar" >> does. > > That's what I thought at first, but in my last message on this issue > I recognized the arguments for the other side. I'm confused now. I've tried to reread all the messages on the subject (especially yours from March 1), but that didn't clear up my confusion. There are two functions we're talking about, expand-file-name and file-relative-name. The current situation is that, at least with Tramp, ".." crosses file handler boundaries. So expand-file-name converts "/foo:/../bar" into "/bar", and hence the name of "/a" relative to the directory "/b:/c" will be something like "../../a" (not sure about the number of ".."). I think your last message says that file-relative-name should never use ".." to cross filehandler or machine boundaries, and that it should instead return absolute filenames in those cases. Q 1: So, should I install Lars' change to file-relative-name? But this leaves me confused w.r.t. expand-file-name. Q 2: Should expand-file-name allow ".." to cross file handlers or machine boundaries? This would mean that (expand-file-name "/foo:/../bar") returns "/bar", instead of "/foo:/../bar". >> One approach that might work is this: if expand-file-name does not >> find a handler, it does its thing and then looks again if it finds a >> handler. Then it invokes that. > > I guess that is necessary. However, once expand-file-name has found > and called one handler, I hope it can avoid looking for another > handler. I will change expand-file-name to look for a handler a second time. This is better than the current behavior, and it can still be changed later to look more often. -- A preposition is not a good thing to end a sentence with.