Re: file-relative-name and remote files

Re: file-relative-name and remote files

[Lars Hansen]

> IMHO, the following might work: file-relative-name finds a filename 
> handler for the filename and one for the directory. If they are 
> different, then the two must come from different handlers, so do like 
> the different-drives case. If they are equal, invoke the handler. This 
> requires a new file operation, file-relative-name. It seems to work 
> for Ange-FTP and Tramp. However... Imagine that there was a filename 
> handler which could look inside of tar files, so that the filename 
> /tmp/foo.tar/x/y would extract the file x/y from the tarball 
> /tmp/foo.tar. So should (file-relative-name "/tmp/foo.tar/x/y" "/tmp") 
> eval to "foo.tar/x/y" or not?


What about changing it to:
file-relative-name finds a filename handler for the filename and one for 
the directory. If they are non-nil and different, then the two must come 
from different handlers, so do like the different-drives case. If they 
are non-nil and equal, or one is non-nil and the other nil, invoke the 
handler. If both are nil, execute the build in code.

Then the handler can decide what to do when one of the files is an 
ordinary one, and in your example it could return "foo.tar/x/y".

Re: file-relative-name and remote files

[Kai Großjohann]

Lars Hansen <larsh@math.ku.dk> writes:

> Then the handler can decide what to do when one of the files is an
> ordinary one, and in your example it could return "foo.tar/x/y".

Your suggestion is a good idea, but it doesn't answer the question:
Should it return "foo.tar/x/y"?

Hm.  But then it would be up to the handler, not to Emacs, so the
change in Emacs could be done right away.  Yes.
-- 
A preposition is not a good thing to end a sentence with.

Re: file-relative-name and remote files

[Stefan Monnier]

> > IMHO, the following might work: file-relative-name finds a filename 
> > handler for the filename and one for the directory. If they are 
> > different, then the two must come from different handlers, so do like 
> > the different-drives case. If they are equal, invoke the handler. This 
> > requires a new file operation, file-relative-name. It seems to work 
> > for Ange-FTP and Tramp. However... Imagine that there was a filename 
> > handler which could look inside of tar files, so that the filename 
> > /tmp/foo.tar/x/y would extract the file x/y from the tarball 
> > /tmp/foo.tar. So should (file-relative-name "/tmp/foo.tar/x/y" "/tmp") 
> > eval to "foo.tar/x/y" or not?
> 
> 
> What about changing it to:
> file-relative-name finds a filename handler for the filename and one for
> the directory. If they are non-nil and different, then the two must come
> from different handlers, so do like the different-drives case. If they
> are non-nil and equal, or one is non-nil and the other nil, invoke the
> handler. If both are nil, execute the build in code.

How about something like:

   (defun f-r-n (filename &optional directory)
     (let* ((dir (if directory (expand-file-name directory) default-directory))
            (file (expand-file-name (file-name-directory filename)))
            (hf (find-file-name-handler file 'file-relative-name))
            (hd (find-file-name-handler dir 'file-relative-name)))
       (cond
        ((not (eq hf hd))
         ;; `filename' and `directory' are on different drives:
         ;; there is hence no relative name from `directory' to `filename'.
         (expand-file-name filename))
        ((null hf)
         ;; Both are plain local: use the builtin code.
         (file-relative-name filename directory))
        ((let ((re (car (rassq hf file-name-handler-alist))))
           (equal (and (string-match re file) (substring file 0 (match-end 0)))
                  (and (string-match re dir) (substring dir 0 (match-end 0)))))
         ;; Both are non-local, use the same handler and same drive name.          
         (file-relative-name filename directory))
        (t
         ;; Both are non-local and on different drives.
         (expand-file-name filename)))))

Note how I check the handler for (file-name-directory filename) rather
than for `filename' so as to avoid uselessly catching jka-compr-style
handlers.


	Stefan

Re: file-relative-name and remote files

[Lars Hansen]

>
>
>How about something like:
>
>   (defun f-r-n (filename &optional directory)
>     (let* ((dir (if directory (expand-file-name directory) default-directory))
>            (file (expand-file-name (file-name-directory filename)))
>            (hf (find-file-name-handler file 'file-relative-name))
>            (hd (find-file-name-handler dir 'file-relative-name)))
>       (cond
>        ((not (eq hf hd))
>         ;; `filename' and `directory' are on different drives:
>         ;; there is hence no relative name from `directory' to `filename'.
>         (expand-file-name filename))
>        ((null hf)
>         ;; Both are plain local: use the builtin code.
>         (file-relative-name filename directory))
>        ((let ((re (car (rassq hf file-name-handler-alist))))
>           (equal (and (string-match re file) (substring file 0 (match-end 0)))
>                  (and (string-match re dir) (substring dir 0 (match-end 0)))))
>         ;; Both are non-local, use the same handler and same drive name.          
>         (file-relative-name filename directory))
>        (t
>         ;; Both are non-local and on different drives.
>         (expand-file-name filename)))))
>
>Note how I check the handler for (file-name-directory filename) rather
>than for `filename' so as to avoid uselessly catching jka-compr-style
>handlers.
>
>
>	Stefan
>  
>
I like the idea. I builds on the assumptions:

1. File names don't have a file-handler invoking syntax that is special 
in the directory part and the base part at the same time.
2. Files not residing in the local directory tree have a file-handler 
invoking syntax that is special in the directory part of the file name.

I guess these assumptions are ok, but if we decide on having them, they 
should be documented.

A minor issue: Your code returns an expanded file name in the cases 
where there is no local name, whereas the existing code in 
file-relative-name returns filename without expansion. We should do the 
same (I prefer expansion) in all cases.

Re: file-relative-name and remote files

[Richard Stallman]

    >            (hf (find-file-name-handler file 'file-relative-name))
    >            (hd (find-file-name-handler dir 'file-relative-name)))

I don't want to introduce a file handler operation for this.
The job is not important enough to justify this,
and it can be done without this anyway (see my earlier message).

Re: file-relative-name and remote files

[Lars Hansen]

>
>
>It seems to me that it is better to let the handler decide.
>
If we want to let the handler decide when filename and directory are in 
the same tree, how would you suggest this should be implemented?

Re: file-relative-name and remote files

[Kai Großjohann]

Lars Hansen <larsh@math.ku.dk> writes:

>>It seems to me that it is better to let the handler decide.
>>
> If we want to let the handler decide when filename and directory are
> in the same tree, how would you suggest this should be implemented?

Hm, err.  Oh, that might mean making file-relative-name a file
operation.  Maybe not so good.  Hm.  The advantage of your suggestion
was to not require a file operation.

So maybe it is better to use your approach after all.  Sorry for the
line-noise.
-- 
A preposition is not a good thing to end a sentence with.

Re: file-relative-name and remote files

[Lars Hansen]

[-- Attachment #1.1: Type: text/plain, Size: 1323 bytes --]

>
>
>Richard has decided that ".." shall not be used to cross file handler
>boundaries.  So file-relative-name needs to be changed to something
>like Lars suggested.
>
>I have some comments/questions about this implementation.
>
>Why the extra arg SEPARATE-TREES?  If I understand Richard correctly,
>he wants file-relative-name to always behave as if SEPARATE-TREES was
>true.
>
I agree, that parameter should be removed.

>>>                   (equal
>>>                     (and
>>>                       (string-match re filename)
>>>                       (substring filename 0 (match-end 0)))
>>>                     (and
>>>                       (string-match re directory)
>>>                       (substring directory 0 (match-end 0)))))))))
>>    
>>
>
>I'm not sure it's a good idea to check this stuff here.  Maybe it
>would be better to let each filename handler do that.
>
>For example, Tramp has the concept of a default method, so
>/user@host:/file and /ssh:user@host:/file denote the same file by
>default, even though the strings are different.
>
>It seems to me that it is better to let the handler decide.
>  
>
I don't see a problem. My implementation calls expand-file-name on
filename as well as directory. I guess that should expand
"/user@host:/file" to e.g. "/ssh:user@host:/file". Am I wrong?


[-- Attachment #1.2: Type: text/html, Size: 1913 bytes --]

[-- Attachment #2: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel

Re: file-relative-name and remote files

[Kai Großjohann]

Lars Hansen <larsh@math.ku.dk> writes:

> I don't see a problem. My implementation calls expand-file-name on
> filename as well as directory. I guess that should expand
> "/user@host:/file" to e.g. "/ssh:user@host:/file". Am I wrong?

No, this does not currently happen.  I used to have such an
expansion, but it caused problems with completion: Emacs got confused
about the length of the string in the minibuffer.

Possibly, the problems were caused by Tramp doing that expansion in
many places, not just expand-file-name.  I should investigate this,
but I haven't done so yet, and I'm not sure when I can find the time.
-- 
A preposition is not a good thing to end a sentence with.

Re: file-relative-name and remote files

[Lars Hansen]

>
>
>Also, this burden is on every file handler.
>Note that every operation needs to do the additional "did it match at
>the beginning" check!
>
>The alternative would be to change expand-file-name as I suggested:
>if there was no handler, do your thing and then look if there is
>another handler to invoke, and if so, then invoke it.
>
>Apart from the implementation considerations, there is also the
>conceptual level: IMHO, the ..-leads-to-different-handler problem is a
>general problem that does not depend on any specific handler.  So this
>general problem should be handled in the general code, rather than
>requiring every handler to deal with this case.
>  
>
Whatever solution is chosen, I think it would be a good idea with some 
general code rather than leaving it to every handler to implement a 
solution.

To me it sounds as a good solution to have expand-file-name, after the 
expansion, check for a handler and call it if one is found, in addition 
to doing it before the expansion. But I think this should be done only 
if we find that it is the correct thin to do from a general point of 
view - not just to solve a specific problem in an easy way. But maybe it 
is the rigth thing. What do people think?

Re: file-relative-name and remote files

[Lars Hansen]

>
>
>I think it is not a good idea to change the filename syntax in such a
>way, for that would mean that people can't use filenames with colons
>in them anymore.  That would be too drastic, I think.
>
>Our BibTeX citation keys are of the form Smith:95, and we store the
>corresponding fulltext documents in files named after the citation
>key.
>
Clearly colons in names of files in directories other than root should
be allowed. Tramp should not barf, it should just call the normal
handler. Would that not work?

Re: file-relative-name and remote files

[Kai Großjohann]

Lars Hansen <larsh@math.ku.dk> writes:

>>I think it is not a good idea to change the filename syntax in such a
>>way, for that would mean that people can't use filenames with colons
>>in them anymore.  That would be too drastic, I think.
>>
>>Our BibTeX citation keys are of the form Smith:95, and we store the
>>corresponding fulltext documents in files named after the citation
>>key.
>>
> Clearly colons in names of files in directories other than root should
> be allowed. Tramp should not barf, it should just call the normal
> handler. Would that not work?

Hm.  Let's see.  Here is what could be done:

* The regexp in file-name-handler-alist is not anchored with ^.

* Every Tramp handler does a second check to see if the match is
  actually at the start of the file.  If so, it does its thing.  If
  not, it invokes the normal operation.

* The expand-file-name operation gets special treatment: there, Tramp
  splits the filename into two parts, the pre-match part and the
  post-match part.  (For a filename "/a/../foo:/bar", the pre-match
  part would be "/a/.." and the post-match part would be
  "/foo:/bar".)  It then invokes the normal operation on the pre-match
  part.  If that results in "/" (or the equivalent of "/" on a
  Windows system), then it does what it does now on the post-match
  part.  If the normal operation returned something different from
  "/", then the result is the result of the normal operation on the
  full string.

I think this might achieve the objective.  It is, however, a rather
complicated algorithm.  Also, this burden is on every file handler.
Note that every operation needs to do the additional "did it match at
the beginning" check!

The alternative would be to change expand-file-name as I suggested:
if there was no handler, do your thing and then look if there is
another handler to invoke, and if so, then invoke it.

Apart from the implementation considerations, there is also the
conceptual level: IMHO, the ..-leads-to-different-handler problem is a
general problem that does not depend on any specific handler.  So this
general problem should be handled in the general code, rather than
requiring every handler to deal with this case.

(However, I am a bit sceptical about arguments on the conceptual
level: I failed to convince people with a similar, conceptual,
argument regarding copy-file.  (copy-file has problem that several
handlers might be involved as the two files might come from different
handlers.  I suggested to add code in copy-file to deal with this
issue, but I think I didn't convince anyone that this is a good idea.
Maybe if I'm successful with the expand-file-name issue, I will bring
up the copy-files issue another time :-)

-- 
A preposition is not a good thing to end a sentence with.

Re: file-relative-name and remote files

[Lars Hansen]

>
>
>But Richard wants to allow ".." to cross file handler boundaries.
>So "/foo:/../bar" should expand to "/bar", just like "/foo/../bar"
>does.
>
>I think that means we're back to square one and we need to find out
>how to deal with things like "/bla/../foo:/bar".  Hm.  Actually, that
>expands to "/foo:/bar" which is fine.  But "/bla/../foo:../bar"
>expands to "/foo:../bar" which is not fine -- it should be expanded
>further.
>
>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.
>
>(Maybe it is easier to implement the previous paragraph by saying,
>after expand-file-name has done its thing in the non-handler case, it
>just reinvokes itself.)
>  
>
Ok, I think I begin to get the right view of things.
If it is still not right, please correct me.

We want to use the file name handler mecanism to make the directory tree
of a remote machine appear as if it was on the local machine in
directory "/foo:". This works by now except that "/bla/../foo:" is not
handeled correctly, because the file handler is not invoced.

Maybe the "/bla/../foo:" problem could be solved the following way:
Change the file handler syntax from "^/[^/:]+:" to "/[^/:]+:" to invoke
Tramp. Let Tramp call expand-file-name on "/bla/..". If this expands to
"/" everything is fine, otherwise barf.

Re: file-relative-name and remote files

[Lars Hansen]

> Maybe the "/bla/../foo:" problem could be solved the following way:
> Change the file handler syntax from "^/[^/:]+:" to "/[^/:]+:" to invoke
> Tramp. Let Tramp call expand-file-name on "/bla/..". If this expands to
> "/" everything is fine, otherwise barf. 


Correction: Not barf, but call the normal handler (to allow files named
"/bla/foo:" to be accessed).

Re: file-relative-name and remote files

[Kai Großjohann]

Lars Hansen <larsh@math.ku.dk> writes:

> Maybe the "/bla/../foo:" problem could be solved the following way:
> Change the file handler syntax from "^/[^/:]+:" to "/[^/:]+:" to invoke
> Tramp. Let Tramp call expand-file-name on "/bla/..". If this expands to
> "/" everything is fine, otherwise barf.

I think it is not a good idea to change the filename syntax in such a
way, for that would mean that people can't use filenames with colons
in them anymore.  That would be too drastic, I think.

Our BibTeX citation keys are of the form Smith:95, and we store the
corresponding fulltext documents in files named after the citation
key.
-- 
A preposition is not a good thing to end a sentence with.

Re: file-relative-name and remote files

[Lars Hansen]

>
>
>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 "..".
>
>What do you think?
>
I see your point. I did not take "~" into consideration. Clearly "~"
should be processed before ".."'s and the file handler should process
"~".
I my opinion that means that everyting after "/foo:" should be handled
as something on the remote machine. I.e. "/foo:/.." should expand to
"/foo:/" and not to "/". And file-relative-name should return an absolute
name when FILENAME and DIRECTORY are on different machines.

Re: file-relative-name and remote files

[Kai Großjohann]

Lars Hansen <larsh@math.ku.dk> writes:

>>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 "..".
>>
>>What do you think?
>>
> I see your point. I did not take "~" into consideration. Clearly "~"
> should be processed before ".."'s and the file handler should process
> "~".

Glad to hear you agree.  I was thinking that I was overlooking
something.

> I my opinion that means that everyting after "/foo:" should be handled
> as something on the remote machine. I.e. "/foo:/.." should expand to
> "/foo:/" and not to "/". And file-relative-name should return an absolute
> name when FILENAME and DIRECTORY are on different machines.

But Richard wants to allow ".." to cross file handler boundaries.
So "/foo:/../bar" should expand to "/bar", just like "/foo/../bar"
does.

I think that means we're back to square one and we need to find out
how to deal with things like "/bla/../foo:/bar".  Hm.  Actually, that
expands to "/foo:/bar" which is fine.  But "/bla/../foo:../bar"
expands to "/foo:../bar" which is not fine -- it should be expanded
further.

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.

(Maybe it is easier to implement the previous paragraph by saying,
after expand-file-name has done its thing in the non-handler case, it
just reinvokes itself.)
-- 
A preposition is not a good thing to end a sentence with.

Re: file-relative-name and remote files

[Lars Hansen]

>
>
>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.

Re: file-relative-name and remote files

[Lars Hansen]

[-- Attachment #1.1: Type: text/plain, Size: 589 bytes --]

>
>
> Lars Hansen <larsh@math.ku.dk> writes:
>
>>> One more problem: The syntax to invoke the Tramp file handler
>>> is "\`/[^/:]+:". So the handler is not invoked in the call
>>> (expand-file-name "/emacs/../larsh@galois.math.ku.dk:."). The
>>> call returns "/larsh@galois.math.ku.dk:." but it should return
>>> "/larsh@galois.math.ku.dk:/home/l/larsh".
>>    
>>
>
>So maybe expand-file-name should re-invoke itself until it reaches a
>fixpoint?
> -- A preposition is not a good thing to end a sentence with.
>
IMHO expand-file-name should remove ".."'s *before* calling file
handlers.


[-- Attachment #1.2: Type: text/html, Size: 1539 bytes --]

[-- Attachment #2: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel

Re: file-relative-name and remote files

[Kai Großjohann]

Lars Hansen <larsh@math.ku.dk> writes:

>> Lars Hansen <larsh@math.ku.dk> writes:
>>
>>>> One more problem: The syntax to invoke the Tramp file handler
>>>> is "\`/[^/:]+:". So the handler is not invoked in the call
>>>> (expand-file-name "/emacs/../larsh@galois.math.ku.dk:."). The
>>>> call returns "/larsh@galois.math.ku.dk:." but it should return
>>>> "/larsh@galois.math.ku.dk:/home/l/larsh".
>>>    
>>
>>So maybe expand-file-name should re-invoke itself until it reaches a
>>fixpoint?
>> -- A preposition is not a good thing to end a sentence with.
>>
> IMHO expand-file-name should remove ".."'s *before* calling file
> handlers.

IMHO expand-file-name should expand "~" even before processing "..".
To expand "~" it is necessary to invoke the handler.

Hm.
-- 
A preposition is not a good thing to end a sentence with.

Re: file-relative-name and remote files

[Lars Hansen]

I suggest the following implementation of file-relative-name.
It does not require a new file handler operation, it detects
remote files in the same way as file-remote-p do. Please see
the doc string for further explanation.

(defun file-relative-name (filename &optional directory separate-trees)
  "Convert FILENAME to be relative to DIRECTORY (default: 
`default-directory').
This function returns a relative file name which is equivalent to FILENAME
when used with that default directory as the default.
If SEPARATE-TREES is non-nil and FILENAME and DIRECTORY lie on different
machines or on different drives (DOS/Windows), it returns FILENAME on
expanded form."
  (save-match-data
    (setq
      directory
      (file-name-as-directory (expand-file-name (or directory 
default-directory))))
    (setq filename (expand-file-name filename))
    (let ((hf (find-file-name-handler filename 'file-local-copy))
          (hd (find-file-name-handler directory 'file-local-copy)))
      (when (and hf (not (get hf 'file-remote-p))) (setq hf nil))
      (when (and hd (not (get hd 'file-remote-p))) (setq hd nil))
      (if
        (and
          separate-trees
          ;; Conditions for separate trees
          (or
            ;; Test for different drives on DOS/Windows
            (and
              (memq system-type '(ms-dos cygwin windows-nt))
              (not (string-equal (substring filename  0 2) (substring 
directory 0 2))))
            ;; Test for different remote file handlers
            (not (eq hf hd))
            ;; Test for different remote file system identification
            (and
              hf
              (let ((re (car (rassq hf file-name-handler-alist))))
                (not
                  (equal
                    (and
                      (string-match re filename)
                      (substring filename 0 (match-end 0)))
                    (and
                      (string-match re directory)
                      (substring directory 0 (match-end 0)))))))))
        filename
        (unless (eq (aref filename 0) ?/) (setq filename (concat "/" 
filename)))
        (unless (eq (aref directory 0) ?/) (setq directory (concat "/" 
directory)))
        (let (
          (ancestor ".")
          (filename-dir (file-name-as-directory filename)))
          (while
            (and
              (not (string-match (concat "^" (regexp-quote directory)) 
filename-dir))
              (not (string-match (concat "^" (regexp-quote directory)) 
filename)))
            (setq
              directory (file-name-directory (substring directory 0 -1))
              ancestor (if (equal ancestor ".") ".." (concat "../" 
ancestor))))
          ;; Now ancestor is empty, or .., or ../.., etc.
          (if (string-match (concat "^" (regexp-quote directory)) filename)
            ;; We matched within FILENAME's directory part.
            ;; Add the rest of FILENAME onto ANCESTOR.
            (let ((rest (substring filename (match-end 0))))
              (if (and (equal ancestor ".") (not (equal rest "")))
                ;; But don't bother with ANCESTOR if it would give us `./'.
                rest
                (concat (file-name-as-directory ancestor) rest)))
            ;; We matched FILENAME's directory equivalent.
            ancestor))))))

Re: file-relative-name and remote files

[Richard Stallman]

    I suggest the following implementation of file-relative-name.
    It does not require a new file handler operation, it detects
    remote files in the same way as file-remote-p do. Please see
    the doc string for further explanation.

This seems like the right general approach for making that change.

Re: file-relative-name and remote files

[Kai Großjohann]

Lars Hansen <larsh@math.ku.dk> writes:

> I suggest the following implementation of file-relative-name.
> It does not require a new file handler operation, it detects
> remote files in the same way as file-remote-p do. Please see
> the doc string for further explanation.

Richard has decided that ".." shall not be used to cross file handler
boundaries.  So file-relative-name needs to be changed to something
like Lars suggested.

I have some comments/questions about this implementation.

> (defun file-relative-name (filename &optional directory separate-trees)
>   "Convert FILENAME to be relative to DIRECTORY (default:
>   default-directory').
> This function returns a relative file name which is equivalent to FILENAME
> when used with that default directory as the default.
> If SEPARATE-TREES is non-nil and FILENAME and DIRECTORY lie on different
> machines or on different drives (DOS/Windows), it returns FILENAME on
> expanded form."

Why the extra arg SEPARATE-TREES?  If I understand Richard correctly,
he wants file-relative-name to always behave as if SEPARATE-TREES was
true.

(Of course, when this message was written, Richard's opinion was
unknown, so it's not your fault, Lars :-)

>   (save-match-data
>     (setq
>       directory
>       (file-name-as-directory (expand-file-name (or directory
>       default-directory))))
>     (setq filename (expand-file-name filename))
>     (let ((hf (find-file-name-handler filename 'file-local-copy))
>           (hd (find-file-name-handler directory 'file-local-copy)))
>       (when (and hf (not (get hf 'file-remote-p))) (setq hf nil))
>       (when (and hd (not (get hd 'file-remote-p))) (setq hd nil))
>       (if
>         (and
>           separate-trees
>           ;; Conditions for separate trees
>           (or
>             ;; Test for different drives on DOS/Windows
>             (and
>               (memq system-type '(ms-dos cygwin windows-nt))
>               (not (string-equal (substring filename  0 2) (substring
>               directory 0 2))))
>             ;; Test for different remote file handlers
>             (not (eq hf hd))
>             ;; Test for different remote file system identification
>             (and
>               hf
>               (let ((re (car (rassq hf file-name-handler-alist))))
>                 (not
>                   (equal
>                     (and
>                       (string-match re filename)
>                       (substring filename 0 (match-end 0)))
>                     (and
>                       (string-match re directory)
>                       (substring directory 0 (match-end 0)))))))))

I'm not sure it's a good idea to check this stuff here.  Maybe it
would be better to let each filename handler do that.

For example, Tramp has the concept of a default method, so
/user@host:/file and /ssh:user@host:/file denote the same file by
default, even though the strings are different.

It seems to me that it is better to let the handler decide.

Opinions?

-- 
A preposition is not a good thing to end a sentence with.

Re: file-relative-name and remote files

[Richard Stallman]

    Richard has decided that ".." shall not be used to cross file handler
    boundaries.

I'd rather say that it seems best if .. does not cross file handler
boundaries.  But I am not entirely sure.  This is a knotty situation,
and neither choice seems entirely right, but it seems that there's a
stronger argument in favor of this approach: it permits constructs
that are impossible the other way.

Re: file-relative-name and remote files

[Lars Hansen]

>
>
>    > file-relative-name assumes that filename and directory is part of the
>    > same tree except when we are on a DOS/Windows system and the first two
>    > chars in the expanded file names (the drive) are not equal. This
>    > approach does not work with remote files. With remote files filename
>    > and directory may reside in different trees.
>
>Could someone please supply an example, so we can see if that is really
>true?  I have doubts about it.  A remote file name in Emacs is simply
>an absolute file name whose first component is special.  Ordinary relative
>names ought to work for them.
>  
>
Any file can be written as a name relative to any directory using the 
".." construct, as long as
both are residing in the same directory tree. The problem is when they 
reside in different trees.
But file-relative-name needs to know when this is so. Try

   (file-relative-name "/dir/file" "/scp:larsh@galois.math.ku.dk:/dir1/")

You need to replace "larsh@galois.math.ku.dk" with a valid user and 
server name,
since the expand-file-name call is handeled by Tramp. The above example
ought to return "/dir/file" since filename is on the local machine and 
directory on the remote,
but in fact it returns "../../dir/file". This makes no sense.
Likewise

   (file-relative-name "/scp:larsh@galois.math.ku.dk:/dir1/file" "/dir/")

ought to return "/scp:larsh@galois.math.ku.dk:dir1/file" but it does return
"../scp:larsh@galois.math.ku.dk:/dir1/file".

>It is possible that it might be preferable to return FILENAME unchanged
>in the case where it and DIRECTORY are on different hosts.
>If so, there is no need for a new file operation.
>You can use file-remote-p to see if either one is remote.
>Then you can see if the names have the same first component.
>
I don't understand the issue about a new file operation. I think we can keep
file-relative-name as a lisp function and implement it along the lines 
proposed by
Stefan Monnier. We just need to decide that it is ok to settle for the 
rules for
file handler invoking syntax I outlined earlier:

1. File names don't have a file-handler invoking syntax that is special 
in the directory part and the base part at the same time.
2. Files not residing in the local directory tree have a file-handler 
invoking syntax that is special in the directory part of the file name.

Re: file-relative-name and remote files

[Stefan Monnier]

>    (file-relative-name "/dir/file" "/scp:larsh@galois.math.ku.dk:/dir1/")
> 
> You need to replace "larsh@galois.math.ku.dk" with a valid user and 
> server name,
> since the expand-file-name call is handeled by Tramp. The above example
> ought to return "/dir/file" since filename is on the local machine and 
> directory on the remote,
> but in fact it returns "../../dir/file". This makes no sense.

Maybe RMS point is that "../../dir/file" *should* make sense and
that it's a bug if Emacs does not handle it properly.


	Stefan

Re: file-relative-name and remote files

[Lars Hansen]

>
>
>Maybe RMS point is that "../../dir/file" *should* make sense and
>that it's a bug if Emacs does not handle it properly.
>
>
>	Stefan
>  
>
Now I see the point. Yes, that might be a good idea. Shouldn't it work 
in that way on
DOS/Windows too? So (file-relative-name "c:/file" "d:/dir/) returns 
"../../c:/file"?
We could add a parameter to file-relative-name specifying whether to map 
into one
tree or not.

Re: file-relative-name and remote files

[Richard Stallman]

    Any file can be written as a name relative to any directory using the 
    ".." construct, as long as
    both are residing in the same directory tree. The problem is when they 
    reside in different trees.

What do you mean by "reside in different trees"?

    But file-relative-name needs to know when this is so. Try

       (file-relative-name "/dir/file" "/scp:larsh@galois.math.ku.dk:/dir1/")

It returns "../../dir/file" which seems correct to me.

    ought to return "/dir/file" since filename is on the local machine and 
    directory on the remote,

It might be useful or convenient to return that instead; I am not
sure.  However, the current value isn't erroneous.

Re: file-relative-name and remote files

[Lars Hansen]

>
>
>What do you mean by "reside in different trees"?
>  
>
I use to think of files as making up a tree structure. Actually it is a
graph rather than tree, because of the possibility of links. What I mean
by "different trees" is what more accurately should be called
non-conneted graphs. As Stefan Monnier pointed out to me, I
misunderstood your last mail. I understand now that the files on eg.
galois.math.ku.dk should be thought of as part of the usual (local) tree
in the directory "/ssh:larsh@galois.math.ku.dk/". There is, however, a
problem. Although  "/ssh:larsh@galois.math.ku.dk:/../emacs/"
and "/emacs/../ssh:larsh@galois.math.ku.dk:/" makes good sense in this
model, it does not work in Emacs:

(file-attributes "/larsh@galois.math.ku.dk:/") =>
(t 21 0 0 (15679 61995) (15917 64402) (15917 64402) 624 "drwxr-xr-x" t
(0 . 2) (-1 0))

(file-attributes "/emacs/") =>
(t 1 123 123 (15592 11887) (15593 21299) (15593 21299) 0 "drwxrwxrwx"
nil 0 (7228 . 7896))

(file-attributes "/larsh@galois.math.ku.dk:/../emacs") =>
nil

(file-attributes "/emacs/../larsh@galois.math.ku.dk:/") =>
nil

It would be nice to make it work, but I guess it is not a small task.
IMHO we should add an optional parameter to file-relative-name
specifying whether files on different machines should be mapped into one
tree or not. If the option is set, I think DOS/windows drives should be
mapped into one tree as well. Eg. (file-relative-name "c:/file"
"d:/dir/) should return "../../c:/file".

Re: file-relative-name and remote files

[Richard Stallman]

I see that (expand-file-name "/larsh@galois.math.ku.dk:/../emacs")
returns "/larsh@galois.math.ku.dk:/../emacs".  That is surprising;
I expected it to return "/emacs".

It would probably be easy to change this, and that change would
probably fix the whole problem.  But was this done intentionally?
Does it serve a specific purpose?

If we don't change this behavior, then we do need to change
file-relative-name.

Re: file-relative-name and remote files

[Lars Hansen]

>
>
>I see that (expand-file-name "/larsh@galois.math.ku.dk:/../emacs")
>returns "/larsh@galois.math.ku.dk:/../emacs".  That is surprising;
>I expected it to return "/emacs".
>
>It would probably be easy to change this, and that change would
>probably fix the whole problem.  But was this done intentionally?
>Does it serve a specific purpose?
>
I doubt that it is intentional, but I don't know. The call is handlede by
Tramp, so it is a Tramp matter.
One more problem: The syntax to invoke the Tramp file handler
is "\`/[^/:]+:". So the handler is not invoked in the call
(expand-file-name "/emacs/../larsh@galois.math.ku.dk:."). The
call returns "/larsh@galois.math.ku.dk:." but it should return
"/larsh@galois.math.ku.dk:/home/l/larsh".

Re: file-relative-name and remote files

[Richard Stallman]

    One more problem: The syntax to invoke the Tramp file handler
    is "\`/[^/:]+:". So the handler is not invoked in the call
    (expand-file-name "/emacs/../larsh@galois.math.ku.dk:."). The
    call returns "/larsh@galois.math.ku.dk:." but it should return
    "/larsh@galois.math.ku.dk:/home/l/larsh".

I am not sure whether "/larsh@galois.math.ku.dk:." is correct, but it
might be.  I don't think it should return
"/larsh@galois.math.ku.dk:/home/l/larsh" because that requires
contacting the remote host, and it is better if expand-file-name does
its work locally.

    Btw, if the part after the colon is not an absolute filename, that is
    interpreted as being relative to the remote home dir.  What happens
    if I open a file "/foo:../bar"?  Is that the same as "/foo:/../bar"
    and therefore the same as "/bar"?

It isn't the same as "/foo:/../bar", just as
"/foo:bar" is not equivalent to "/foo:/bar".

Hmm, this raises the issue of what expand-file-name should do with
"/foo:../..".  I guess it must leave that unchanged, which means that
the expand-file-name handler for these file names should be rather
careful in what it does to simplify whatever part of the name comes
after.  It is not correct to simplify /X/../Y into /Y when /X
is a remote prefix.

This seems to have implications about file-relative-name.  Suppose we
ask for

  (file-relative-name "/a/b" "/foo@quux:../../")

I think in this case there is no correct relative file name that it
could return.  The only correct value to return is an absolute file
name in this case.

This seems to prove that the proposed change in file-relative-name
should be made.

Re: file-relative-name and remote files

[Lars Hansen]

Richard Stallman wrote:

>Hmm, this raises the issue of what expand-file-name should do with
>"/foo:../..".  I guess it must leave that unchanged, which means that
>the expand-file-name handler for these file names should be rather
>careful in what it does to simplify whatever part of the name comes
>after.  It is not correct to simplify /X/../Y into /Y when /X
>is a remote prefix.
>  
>
I do not agree. Let me try to explain why.

One might describe ".." as "the parent directory". This makes good sense 
when files make up a tree, because in that case each file (except the 
root) has exactly one parent. However, as I mentioned earlier, files do 
not in general make up a tree, they make up a more general graph. A file 
might have more than one parent. An example is the file

  /foo:x

This file should be thought of as "the file x on the remote computer" as 
well as "the file "/foo:x" on the local computer. The file has (at 
least) two parents: The parent of x on the
remote computer and the parent of "/foo:x" on the local computer, i.e. 
the root on the local computer.

The fact that a file can have more than one parent is *not* special for 
the construct above. On a unix like system we have links. Consider the 
following example:

  galois:~/> mkdir y
  galois:~/> cd y
  galois:~/y/> mkdir x
  galois:~/y/> cd x
  galois:~/y/x/> ln -s ../x

Now the file x has two parents: y and itself! How does the system then 
decide what ".." should refer to? Take a look:

  galois:~/y/x/> cd x
  galois:~/y/x/x/> cd ..
  galois:~/y/x/> cd ..
  galois:~/y/>

We have a path to x, and ".." refers to the parent in that path. In the 
first "cd .." above ".." means x, in the second it means y.

In my opinion we should use the same strategy with remote files. Just as 
in the example above there is more than one path from a computer to the 
file y in my home directory on galois:

  /larsh@galois.math.ku.dk:y
  /larsh@galois.math.ku.dk:/home/l/larsh/y

In the first case ".." should refer to the root on the local machine, in 
the second case it should refer to the directory /home/l/larsh on the 
remote machine.

Thus I think that "/foo:../.." should refer to the root on the local 
machine (just like "/foo:bar/.." for any choice of "bar"). If you want 
to access files above the home directory on the remote machine, you 
should choose a path via the root on the remote machine.

Re: file-relative-name and remote files

[Kai Großjohann]

Richard Stallman <rms@gnu.org> writes:

> Hmm, this raises the issue of what expand-file-name should do with
> "/foo:../..".  I guess it must leave that unchanged, which means that
> the expand-file-name handler for these file names should be rather
> careful in what it does to simplify whatever part of the name comes
> after.  It is not correct to simplify /X/../Y into /Y when /X
> is a remote prefix.

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?

-- 
A preposition is not a good thing to end a sentence with.

Re: file-relative-name and remote files

[Richard Stallman]

    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]

Richard Stallman <rms@gnu.org> 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.

Re: file-relative-name and remote files

[Richard Stallman]

    There are two functions we're talking about, expand-file-name and
    file-relative-name.

The questions are linked.  If expand-file-name lets .. get rid
of a remote prefix, then file-relative-name can use .. to do that.
If expand-file-name does not let .. cancel a remote prefix,
then file-relative-name should treat the local and remote names
as being in "separate trees"; it should return an absolute file name
when the DIRECTORY arg includes a remote prefix and FILENAME does not.
For symmetry, it should also return an absolute file name when
the FILENAME arg includes a remote prefix and DIRECTORY does not.

I am leading towards thinking that we should choose the second
alternative.  That means installing Lars' change in file-relative-name,
and changing Tramp so that (expand-file-name "/foo:/../bar")
returns "/foo:/../bar".

The change we're considering in expand-file-name seems to be needed also.

Re: file-relative-name and remote files

[Kai Großjohann]

Lars Hansen <larsh@math.ku.dk> writes:

> One more problem: The syntax to invoke the Tramp file handler
> is "\`/[^/:]+:". So the handler is not invoked in the call
> (expand-file-name "/emacs/../larsh@galois.math.ku.dk:."). The
> call returns "/larsh@galois.math.ku.dk:." but it should return
> "/larsh@galois.math.ku.dk:/home/l/larsh".

So maybe expand-file-name should re-invoke itself until it reaches a
fixpoint?
-- 
A preposition is not a good thing to end a sentence with.

Re: file-relative-name and remote files

[Richard Stallman]

    So maybe expand-file-name should re-invoke itself until it reaches a
    fixpoint?

There is surely no need for that.  One pass through expand-file-name
can directly do all the expansion that ought to be done.  The question
is precisely what it should do.

Re: file-relative-name and remote files

[Kai Großjohann]

Richard Stallman <rms@gnu.org> writes:

> I see that (expand-file-name "/larsh@galois.math.ku.dk:/../emacs")
> returns "/larsh@galois.math.ku.dk:/../emacs".  That is surprising;
> I expected it to return "/emacs".
>
> It would probably be easy to change this, and that change would
> probably fix the whole problem.  But was this done intentionally?
> Does it serve a specific purpose?
>
> If we don't change this behavior, then we do need to change
> file-relative-name.

In my mind, filenames are a forest, rather than a tree.  For me, the
name of a remote file is firmly separated into two parts: one part
that specifies the host, and another part that specifies the file on
that host.  So opening the file /larsh@galois.math.ku.dk:/../emacs
should behave the same as logging in to the host galois, then opening
the file /../emacs there.  If galois is a Unix host, then /../emacs
should be the same as /emacs.  Therefore, (expand-file-name
"/larsh@galois.math.ku.dk:/../emacs") should evaluate to
"/larsh@galois.math.ku.dk:/emacs".  (It seems that Tramp has a bug in
that it fails to remove the "/.." part.)

I could not imagine in my wildest dreams that one could use relative
file names (in particular, using "..") to cross host boundaries.

Does this explain where the current behavior comes from?  (Modulo
that bug where expand-file-name fails to remove "..".)

But I see that it is wrong to assume that filenames are a forest.
Instead, it is right to assume they are a tree.

I will change expand-file-name so that "/foo:/../bar" is handled
correctly.

Btw, if the part after the colon is not an absolute filename, that is
interpreted as being relative to the remote home dir.  What happens
if I open a file "/foo:../bar"?  Is that the same as "/foo:/../bar"
and therefore the same as "/bar"?

-- 
A preposition is not a good thing to end a sentence with.

Re: file-relative-name and remote files

[Kai Großjohann]

Richard Stallman <rms@gnu.org> writes:

> I see that (expand-file-name "/larsh@galois.math.ku.dk:/../emacs")
> returns "/larsh@galois.math.ku.dk:/../emacs".  That is surprising;
> I expected it to return "/emacs".

I've explained previously why I think that

(expand-file-name "/larsh@galois.math.ku.dk:/../emacs")
=> "/larsh@galois.math.ku.dk:/emacs"

should hold.  Now I found the explanation why the "/.." part remains
in the filename.  Viz,

(expand-file-name "/../tmp") => "/../tmp"

Should this be changed?  What should the result be?
-- 
A preposition is not a good thing to end a sentence with.

Re: file-relative-name and remote files

[Andreas Schwab]

kai.grossjohann@uni-duisburg.de (Kai Großjohann) writes:

|> Richard Stallman <rms@gnu.org> writes:
|> 
|> > I see that (expand-file-name "/larsh@galois.math.ku.dk:/../emacs")
|> > returns "/larsh@galois.math.ku.dk:/../emacs".  That is surprising;
|> > I expected it to return "/emacs".
|> 
|> I've explained previously why I think that
|> 
|> (expand-file-name "/larsh@galois.math.ku.dk:/../emacs")
|> => "/larsh@galois.math.ku.dk:/emacs"
|> 
|> should hold.  Now I found the explanation why the "/.." part remains
|> in the filename.  Viz,
|> 
|> (expand-file-name "/../tmp") => "/../tmp"
|> 
|> Should this be changed?  What should the result be?

IIRC there are systems where "/.." has a different meaning than "/".

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux AG, Deutschherrnstr. 15-19, D-90429 Nürnberg
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: file-relative-name and remote files

[Kai Großjohann]

Andreas Schwab <schwab@suse.de> writes:

> IIRC there are systems where "/.." has a different meaning than "/".

Really?  Whee.  Can Tramp be used to connect to them?  If it can,
then maybe it shouldn't interpret such filenames.

(Which systems are you talking about, btw?)
-- 
A preposition is not a good thing to end a sentence with.

Re: file-relative-name and remote files

[Andreas Schwab]

kai.grossjohann@uni-duisburg.de (Kai Großjohann) writes:

|> Andreas Schwab <schwab@suse.de> writes:
|> 
|> > IIRC there are systems where "/.." has a different meaning than "/".
|> 
|> Really?  Whee.  Can Tramp be used to connect to them?  If it can,
|> then maybe it shouldn't interpret such filenames.
|> 
|> (Which systems are you talking about, btw?)

I can't remember, but I think it has a similar meaning as the "//" special
case on some other systems.  Both "//" and "/.." are not required to be
the same as "/" according to POSIX.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux AG, Deutschherrnstr. 15-19, D-90429 Nürnberg
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: file-relative-name and remote files

[Miles Bader]

On Fri, Feb 28, 2003 at 04:43:48PM +0100, Andreas Schwab wrote:
> I can't remember, but I think it has a similar meaning as the "//" special
> case on some other systems.  Both "//" and "/.." are not required to be
> the same as "/" according to POSIX.

CMU CS used to have a remote filesystem that used `/..' as a meta-root
(I think it was developed as part of the spice project [precursor of mach]).
I'm not sure if that's still used anywhere though.

-Miles
-- 
We live, as we dream -- alone....

Re: file-relative-name and remote files

[Stefan Monnier]

> > I can't remember, but I think it has a similar meaning as the "//" special
> > case on some other systems.  Both "//" and "/.." are not required to be
> > the same as "/" according to POSIX.
> 
> CMU CS used to have a remote filesystem that used `/..' as a meta-root
> (I think it was developed as part of the spice project [precursor of mach]).
> I'm not sure if that's still used anywhere though.

IIRC it was called RFS (remote file system) and basically behaved
more or less like the typical /net thingy, although the underlying
system was different.
IIRC Domain OS (i.e. Apollo's operating system) also had something
special for /.. but since I've never used such a system I'd be surprised
to remember correctly.


	Stefan

Re: file-relative-name and remote files

[Andreas Schwab]

"Stefan Monnier" <monnier+gnu/emacs@rum.cs.yale.edu> writes:

|> IIRC Domain OS (i.e. Apollo's operating system) also had something
|> special for /.. but since I've never used such a system I'd be surprised
|> to remember correctly.

I remember now, that was the system I was thinking of.  They had some
other quite interesting features, like environment variable expansion in
symlinks targets.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux AG, Deutschherrnstr. 15-19, D-90429 Nürnberg
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: file-relative-name and remote files

[Kai Großjohann]

"Stefan Monnier" <monnier+gnu/emacs@rum.cs.yale.edu> writes:

> IIRC it was called RFS (remote file system) and basically behaved
> more or less like the typical /net thingy, although the underlying
> system was different.
> IIRC Domain OS (i.e. Apollo's operating system) also had something
> special for /.. but since I've never used such a system I'd be surprised
> to remember correctly.

It seems that these are a bit esoteric, but maybe it's just my lack
of knowledge.

So is it okay for Tramp to interpret /user@host:/../local/name as
being the same as /local/name or should I change this?

-- 
A preposition is not a good thing to end a sentence with.

Re: file-relative-name and remote files

[Richard Stallman]

    So is it okay for Tramp to interpret /user@host:/../local/name as
    being the same as /local/name or should I change this?

If there are no file systems in use nowadays that treat /.. specially,
then I guess it does not matter.

file-relative-name and remote files

[Lars Hansen]

file-relative-name assumes that filename and directory is part of the 
same tree except when we are on a DOS/Windows system and the first two 
chars in the expanded file names (the drive) are not equal. This 
approach does not work with remote files. With remote files filename and 
directory may reside in different trees. Since the syntax of remote 
files just is a prefix to an ordinary file name, it should be a matter 
of comparing prefixes, just as in the DOS/Windows case. However, remote 
files are handled by the file name handler mechanism which does not work 
for file-relative-name, since file-relative-name is a lisp function.

What would be the best way to solve this problem?

Re: file-relative-name and remote files

[Kai Großjohann]

Lars Hansen <larsh@math.ku.dk> writes:

> file-relative-name assumes that filename and directory is part of the
> same tree except when we are on a DOS/Windows system and the first two
> chars in the expanded file names (the drive) are not equal. This
> approach does not work with remote files. With remote files filename
> and directory may reside in different trees. Since the syntax of
> remote files just is a prefix to an ordinary file name, it should be a
> matter of comparing prefixes, just as in the DOS/Windows
> case. However, remote files are handled by the file name handler
> mechanism which does not work for file-relative-name, since
> file-relative-name is a lisp function.
>
> What would be the best way to solve this problem?

Whee.  Good spotting.  IMHO, the following might work:

file-relative-name finds a filename handler for the filename and one
for the directory.  If they are different, then the two must come
from different handlers, so do like the different-drives case.  If
they are equal, invoke the handler.

This requires a new file operation, file-relative-name.  It seems to
work for Ange-FTP and Tramp.  However...

Imagine that there was a filename handler which could look inside of
tar files, so that the filename /tmp/foo.tar/x/y would extract the
file x/y from the tarball /tmp/foo.tar.  So should
(file-relative-name "/tmp/foo.tar/x/y" "/tmp") eval to "foo.tar/x/y"
or not?
-- 
A preposition is not a good thing to end a sentence with.

Re: file-relative-name and remote files

[Richard Stallman]

    > file-relative-name assumes that filename and directory is part of the
    > same tree except when we are on a DOS/Windows system and the first two
    > chars in the expanded file names (the drive) are not equal. This
    > approach does not work with remote files. With remote files filename
    > and directory may reside in different trees.

Could someone please supply an example, so we can see if that is really
true?  I have doubts about it.  A remote file name in Emacs is simply
an absolute file name whose first component is special.  Ordinary relative
names ought to work for them.

It is possible that it might be preferable to return FILENAME unchanged
in the case where it and DIRECTORY are on different hosts.
If so, there is no need for a new file operation.
You can use file-remote-p to see if either one is remote.
Then you can see if the names have the same first component.

Re: file-relative-name and remote files

[Kai Großjohann]

Lars Hansen <larsh@math.ku.dk> writes:

> file-relative-name assumes that filename and directory is part of the
> same tree except when we are on a DOS/Windows system and the first two
> chars in the expanded file names (the drive) are not equal.

I've now changed Tramp such that (expand-file-name
"/user@host:/../foo") evals to "/foo".

    (Aside: It's not clear to me what (expand-file-name
    "/user@host:../foo") should eval to.  Usually, relative localnames
    (the ../foo part) are considered to be relative to the remote home
    dir.  Any advice?)

Does this change make things Just Work, or is a change in
file-relative-name still required?
-- 
A preposition is not a good thing to end a sentence with.