Re: file-relative-name and remote files

[Kai Großjohann]

Richard Stallman <address@hidden> 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.