From: Lars Hansen <larsh@math.ku.dk>
Subject: Re: Emacs-devel Digest, Vol 4, Issue 19
Date: Sat, 08 Mar 2003 09:32:14 +0100 [thread overview]
Message-ID: <3E69AA8E.6020404@math.ku.dk> (raw)
In-Reply-To: <E18rQiV-0004PA-00@monty-python.gnu.org>
>
>
>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 "/root@foo:../..", where the ~root on the remote host
>is "/root", the result will be "/root@foo:/..", 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
"/root@foo:/.." should be interpreted as it would on the remote machine,
i.e. "/root@foo:/.." should normally expand to "/root@foo:/".
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 "/root@foo:/.." 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.
next parent reply other threads:[~2003-03-08 8:32 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <E18rQiV-0004PA-00@monty-python.gnu.org>
2003-03-08 8:32 ` Lars Hansen [this message]
2003-03-08 14:39 ` Emacs-devel Digest, Vol 4, Issue 19 Kai Großjohann
2003-03-10 1:56 ` Miles Bader
2003-03-08 8:38 ` file-relative-name and remote files Lars Hansen
2003-03-08 8:46 ` Lars Hansen
2003-03-08 14:41 ` Kai Großjohann
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3E69AA8E.6020404@math.ku.dk \
--to=larsh@math.ku.dk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.