|
From: | Lars Hansen |
Subject: | Re: file-relative-name and remote files |
Date: | Sat, 08 Mar 2003 09:38:26 +0100 |
User-agent: | Mozilla/5.0 (Windows; U; Win 9x 4.90; en-US; rv:1.2.1) Gecko/20021130 |
Actually, what Tramp does to expand "/foo:../.." is the following: * The localname part ("../..") is not absolute, so it must be relative to the remote home dir. Prepend "~/" to the localname, giving "/foo:~/../..". * Expand tildes, giving, say, "/foo:/home/jrl/../..". * Expand the localname part, giving "/", then tack on the prefix. The final result is "/foo:/". Is this the right behavior so far? In the case of "/address@hidden:../..", where the ~root on the remote host is "/root", the result will be "/address@hidden:/..", which is not pretty. Maybe this should be expanded, again, to "/". WDYT?
One might look at file name in the following two ways: 1. An optional remote prefix followed by something. 2. A sequence of strings separated by slashes. Which view should be given highest precedence? If the first view is given the highest precedence, I think the "/.." part of "/address@hidden:/.." should be interpreted as it would on the remote machine, i.e. "/address@hidden:/.." should normally expand to "/address@hidden:/". In this case a file cannot be named relative to a directory if the file and the directory are on different machines. If the second view is given the highest precedence, "/x/.." should expand to "/" independently of what "x" is. Thus "/address@hidden:/.." as well as "/foo:../.." should expand to "/". In this case a file can always be named relative to a directory. In this case expand-file-name should be changed to remove ".."'s *before* file handlers are called. IMHO the two choises of precedence should not be mixed.
[Prev in Thread] | Current Thread | [Next in Thread] |