GNU bug report logs -
#7159
24.0.50; (1) `file-name-(non)directory': bad return values, (2) `directory-sep-char'
Previous Next
Reported by: "Drew Adams" <drew.adams <at> oracle.com>
Date: Mon, 4 Oct 2010 17:59:02 UTC
Severity: minor
Tags: wontfix
Found in version 24.0.50
Done: "Drew Adams" <drew.adams <at> oracle.com>
Bug is archived. No further changes may be made.
Full log
Message #22 received at 7159-done <at> debbugs.gnu.org (full text, mbox):
> From: "Drew Adams" <drew.adams <at> oracle.com>
> Cc: <7159-done <at> debbugs.gnu.org>
> Date: Tue, 5 Oct 2010 07:58:23 -0700
>
> > What other real-life use-cases exist that require such a
> > functionality?
>
> Ah, the "real world" argument.
What argument? I asked a reasonable question, and as someone who
requests to change existing APIs, it is not unreasonable to expect a
decent answer. At the very least, you could tell about your own
use-case, which prompted you to ask for this.
If you aren't prepared to present your case, then I don't see any
reason to continue discussing this, let alone consider any changes in
veteran and well-established APIs.
> Answers: (1) Users and programs will always do what you don't expect - and
> sometimes there is no reason they shouldn't. (2) Occam's razor: There is no
> reason to special-case backslash here: slash alone is sufficient. If not true,
> then treat ?\ as a dir separator in Emacs on Unix also.
That's not an answer, sorry. I asked for specific, practical
use-cases, not about theoretical "why not?" philosophical arguments.
We don't generally implement in Emacs APIs for situations that don't
happen in practice. Life's too short.
> You already agreed that the argument need not be a file name.
No, I didn't. I agreed that the argument need not name an existing
file. But it still must be a valid file name, by the rules of the
underlying filesystem. We sometimes extend these rules (cf. Tramp and
the "remote" file names in general) to allow Emacs-specific features,
but we never restrict them.
> > No. They are designed to parse file names that are valid on the
> > underlying OS.
>
> That's where we disagree.
Yes, we do.
> These functions should know nothing about the underlying OS. They should be
> handed _Emacs_ file names, that is, names with ?/ as the dir separator.
Not going to happen. At most, you may have (or write) additional
functions. An attempt at imposing on the Emacs developers to go
through all the sources and change code that works perfectly well is
not going to fly.
> > But we already use that "other code": these two primitives (and
> > others) which DTRT with any file name that is valid on Windows.
> > There's no need to change anything.
>
> It should be clear from my use above that by "other" I meant "other than these
> functions". These standard functions should be only for operating on Emacs file
> names. "Other" means platform-specific translation to platform-independent
> Emacs file names (with ?/ separators).
What is so special about "these" functions that you insist that they
and only they do what you want? What's in a name?
> This is about separating out the platform-specific treatment to only the places
> where it is needed
My point, which I obviously fail to drive home, is that they are
needed everywhere where we use file names in Emacs.
> (standard-file-name the-input) is exactly what we should have.
Please take a second look at that function (or, rather, at
w32-convert-standard-filename, its w32 implementation). You will see
that it does things that are far from the "simple" slash parsing you
asked for. For example, if we use w32-convert-standard-filename
indiscriminantly, as you suggest, we will be unable to support remote
file names on Windows.
> The point is that at places in the code where you see (file-name-directory
> (standard-file-name the-input)) it will be clear that `the-input' might not be
> in the standard Emacs format (with only ?/ as dir separator).
You are asking Emacs developers to:
. find all the places in Lisp code that may potentially get file
names with backslashes
. add a call to some function to all those places
. somehow remember to insert a call to that function to any place in
future Lisp code that is added to Emacs
. remember to teach all Emacs contributors who work on platforms
other than Windows to use that paradigm in their contributions
All that when we already have APIs that work correctly everywhere, and
don't suffer from the above maintenance burden. Now, please try to
guess what are the chances of this to happen, even if I did agree with
your arguments.
> More typically, such places will call `standard-file-name' only once to convert
> the external input once and for all.
There _is_ no "only once". Emacs does not get _filenames_ from all
those sources, it gets _text_. To understand which parts of that text
are file names, it needs to analyze the text. That analysis is not
always in a single place and on a single level. All those places need
to be changed, and for no good reason, because they already work fine.
> > But here's one more example I just recalled: type
> > "M-x getenv RET PATH RET" and look at the value. I'm sure if I think
> > more, I will recall more examples. But why waste energy on a problem
> > that doesn't exist?
>
> To convert a PATH you need only iterate wrt `path-separator', calling
> `standard-file-name' on each path component.
That would break some programs when Emacs invokes them on Windows and
DOS, because they are not prepared to handle directories with forward
slashes in PATH. That's the reason we don't translate PATH to use
forward slashes to begin with.
You see, life isn't as simple as you think it is. Please try to give
a bit more respect to what we have now in Emacs, and please don't
assume that its current shape is due to some omission or lack of
foresight, but rather that it's based on a lot of experience and grey
hair.
> Please leave the bug report open, for possible consideration in the future or by
> others.
No. The bug is there for everyone to see and "consider", but there's
no reason to leave it open, because I will do my best to block any
"fixes" like that to those APIs.
This bug report was last modified 14 years and 235 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.