bug#7159: 24.0.50; (1) `file-name-(non)directory': bad return values, (2) `directory-sep-char'

[Eli Zaretskii]

> From: "Drew Adams" <drew.adams@oracle.com>
> Date: Mon, 4 Oct 2010 10:59:12 -0700
> Cc: 
> 
> BUT:
>  
> (file-name-directory    titi) ; gives "c:/foo/bar/b[^^@]*\\.el\\"
> (file-name-nondirectory titi) ; gives "'"
>  
> These functions should know how to parse titi to produce "c:/foo/bar/"
> and "b[^^@]*\\.el\\'", respectively (where ^@ is the control char).

You are forgetting the backslashes that wildcard-to-regexp inserted.
On DOS and Windows, Emacs treats backslashes as directory separators,
as you'd expect.  So "c:/foo/bar/b[^^@]*\\.el\\" looks like a leading
directory of a file whose basename is "'".

In other words, don't pass a regexp with backslashes to these
functions, because you won't get what you think you will.

> It is not expected that these functions return names that necessarily
> map to actual directories or files.

And indeed, they don't.

> So I suspect that the `file-name-nondirectory' part of this bug
> is at least in part a Windows problem.  The code seems to be
> interpreting the backslash (?\) near the end as a directory
> separator.

It does, by design.

> If so, that is definitely wrong.  Even on Windows, the
> code should use the value of `directory-sep-char', which is ?/,
> not ?\.

On Windows, we support both, and we always will.  Anything else means
a terrible breakage, believe me.  For example, it would be very hard
to parse output of programs that emit file name with backslashes.
With the current setup, this is seamless, even if the file names use
mixed forward- and back-slashes (yes, it happens with GCC and GDB, for
example, or even with Make sometimes).

> However, I see from the doc string that `directory-sep-char' has
> been made obsolete:

In fact, just yesterday it was removed altogether, because it has not
effect on what Emacs does.  That's been like that for years, and we
saw no complains.

I'm closing this bug.