Re: (concat "/dir/name/" "foo") --> (expand-file-name "foo" "/dir/name/")

[prj@po.cwru.edu (Paul Jarc)]

Dave Love <d.love@dl.ac.uk> writes:
> I don't understand this.  One of the points about expand-file-name is
> that it gets to do magic depending on the file name.

Right.  Now suppose you have a file name that would invoke magic if
expanded, but that you want to interpret literally - maybe it came
from directory-files, for example - so it might contain arbitrary
characters, but you know that it needs no massaging to become the name
of an actual file.  In that case, expand-file-name won't necessarily
give you the file name you want.

>  PJ> I think file-name-as-directory and directory-file-name are
>  PJ> idempotent on all platforms, although they aren't documented as
>  PJ> such, AFAICT.
> 
> I'm not sure why that's relevant,

I'm not sure *that* it's relevant.  I mentioned it only in passing.

> but even if it's generally true in the absence of handlers -- I
> don't know -- I don't think you can say what a random handler might
> do, e.g. for remote files on an arbitrary system.

expand-file-name, file-name-as-directory and directory-file-name are
just string operations.  Handlers aren't involved until I/O is
attempted, AFAIK.


paul