[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: file-relative-name and remote files
From: |
Richard Stallman |
Subject: |
Re: file-relative-name and remote files |
Date: |
Sun, 16 Mar 2003 23:52:21 -0500 |
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?
I wouldn't say it is wrong, but it has a drawback: expanding the
remote ~/ requires getting info from the remote machine, which is
slow (for this operation).
I don't see an obvious better alternative, though.
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?
They both make logical sense, and the second is much easier for Emacs
to implement, but I think the former is more useful.
That just doesn't make sense. It neglects "~". IMHO, a filename
such as "~/../bla" makes perfect sense, and I think that "~" should
be expanded first, before processing "..".
It doesn't address the question of what to do with "~", but I would not
say that makes it nonsense.
expand-file-name does handle "~" the way you suggest.
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.
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.
- Re: file-relative-name and remote files, Kai Großjohann, 2003/03/01
- Re: file-relative-name and remote files, Kai Großjohann, 2003/03/07
- Re: file-relative-name and remote files, Lars Hansen, 2003/03/08
- Re: file-relative-name and remote files, Lars Hansen, 2003/03/08
- Re: file-relative-name and remote files, Lars Hansen, 2003/03/08
- Re: file-relative-name and remote files, Lars Hansen, 2003/03/11