Re: Change in expand-file-name in Emacs
"Stephen J. Turnbull" <stephen(a)xemacs.org> writes:
>>>>> "Kai" == Kai Großjohann
<kai.grossjohann(a)gmx.net> writes:
Kai> Maybe you want to do this in XEmacs, too?
Kai> "Stephen J. Turnbull" <stephen(a)xemacs.org> writes:
>> Possibly. Why would such a path arise in practice?
Kai> Who's to know?
Well, since to my mind the semantics of looking up "~" for remote
hosts (which may not even grok the concept) are questionable, I'd like
to know where this is going. I think it's very reasonable to have a
facility which does completion etc on remote paths for interactive
use, but non-interactive, I don't know about that. I've never seen an
expand-file-name call wrapped in a condition-case. ;-) So I'd like
to see examples where it's useful, so I can wrap my brain around
intended semantics.
It seems I misunderstood. I thought you were only talking about the
".." interpretation. But it turns out you're talking about the
interpretation of "~" for remote files.
In order to avoid mixing the two in one test case, let's look at the
following filename: "/a/b/../../user＠host:/c/d/../e"
The old implementation of expand-file-name returns
"/user＠host:/c/d/../e". With my change, it returns
"/user＠host:/c/e", ie it also processes the last occurrence of "..".
[time passes, checking]
Oh! I now see that the current version does process all occurrences
of ".." in the path "/tmp/../kai＠localhost:/home/kai/../foo" -- it
returns "/kai＠localhost:/home/foo".
Okay, then, let's talk about the semantics of "~" instead.
Also, I'm not sure that I agree that the proper interpretation
of
"/x/../me＠home.net:/~" is "/me＠home.net:/home/me". That's mixing
two
different purely textual manipulations. It's so subtle I'm not even
sure it matters ... but it makes me nervous.
Maybe we should talk about "/user＠host:~/foo". That should expand to
"/user＠host:/home/foo", IMHO. And this is indeed what EFS does.
What should be the result of "/x/../me＠home.net:/a/b"?
Maybe you're proposing that it should return "/:/me＠home.net:/a/b".
(This is an Emacsism which does not appear to exist on XEmacs. The
leading "/:" means to interpret the rest of the file name as a normal
file name even if it matches some patterns in
file-name-handler-alist. This means that "/:/me＠home.net:/" refers
to a directory on the local host, and the name of this directory just
happens to contain "＠" and end in ":".)
Kai> expand-file-name *is* a file operation.
As far I can tell from the documentation, it's intended to be an
operation on strings. It is not supposed to actually attempt to look
up the path on the system.
This is true for "." and ".." processing. But ~ expansion needs to
know the home dir, so it needs to look on the remote host.
But what I meant by saying it's a file operation is that
expand-file-name looks to see if its arg matches a regexp from
file-name-handler-alist. This does not necessarily imply any disk
access. It just implies that file handlers can provide their own
implementation of expand-file-name.
I suppose it's reasonable to interpret that you should look up
the
user name on the remote system, but it's equally reasonable to
interpret that as an attempt to access the path
Which path?
(which is not necessary for a local name; although lookups in
/etc/passwd or whatever access the file system, they do not attempt
to access any part of the path being computed, except / of course
;-). On systems using NIS or similar, this might not even involve
any file system lookup by XEmacs at all!
Kai> ITYM "/me＠home.net:~", with the leading slash?
Yes.
Kai> The behavior of expand-file-name in this case hasn't changed.
Blech. You're right.
I can only imagine that there are no practical non-interactive
situations in which this is desirable, or we would have had bug
reports about bogus net accesses when disconnected. (Note that in
that case expand-file-name will throw an error (I assume; it throws
one for a non-existent host) and thus if you have such an expression
in init.el, the init file breaks.) Lack of such reports (init file or
in general) suggests people hardly ever use this feature of
expand-file-name.
Anyway, you're obviously making things more consistent since EFS does
provide a handler for expand-file-name, and on that basis I won't
object to a patch to 21.5 if you or someone else submits one. (I may
however produce a counter-patch to avoid this behavior, at least to be
user-configurable.:-)
Okay. Here's another one; maybe this example convinces you. It does
not use "~" at all.
(expand-file-name "/..") returns "/..". And (expand-file-name
"/user＠host:/..") returns "/user＠host:/..". This is the way it
should be, since "/.." is used as the prefix for AFS or some other
such filesystem. This means that people who wish to use EFS to
access another host which just happens to provide an AFS filesystem,
and said people would like to access that, then they need to use
"/user＠host:/../some/file".
Note: Actually, XEmacs does (expand-file-name "/user＠host:/..")
=> "/user＠host:/". I guess this is a bug. Emacs behaves as I
describe. Let's just pretend that XEmacs behaves the same as
Emacs, for the time being...
But (expand-file-name "/a/../user＠host:/..") would not invoke a file
handler, and thus it would process both ".." locally, resulting in
"/".
IMHO, expand-file-name on "/a/../something" should be the same as
expand-file-name on "/something".
With my change, this happens. Without my change, expand-file-name
produces different results for "/a/../something" and "/something",
for certain values of "something".
You were also talking about interactivity. It's not quite clear to
me what that means. Why is it important whether expand-file-name is
invoked after the user hits TAB in the C-x C-f prompt or at some
other time?
--
A preposition is not a good thing to end a sentence with.