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

Previous Next

Full log

Message #18 received at 7159-done <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Drew Adams <drew.adams <at> oracle.com>
Cc: 7159-done <at> debbugs.gnu.org
Subject: Re: bug#7159: 24.0.50;
	(1) `file-name-(non)directory': bad return values,
	(2)	`directory-sep-char'
Date: Tue, 05 Oct 2010 06:10:48 +0200

> From: "Drew Adams" <drew.adams <at> oracle.com>
> Cc: <7159-done <at> debbugs.gnu.org>
> Date: Mon, 4 Oct 2010 15:22:26 -0700
> 
> Well, let me put it another way: That is just what this bug report is about:
> Backslashes are NOT directory separators for Emacs - or at least they should not
> be.  Even on Windows.

We will have to disagree on that.  I've been porting Unix programs to
DOS and Windows for the last 20 years, and in my experience, any
program that does not treat these two flavors equivalently is
fundamentally broken on these systems.

> > In other words, don't pass a regexp with backslashes to these
> > functions, because you won't get what you think you will.
> 
> Correction: You won't get what you should get, which is just the
> directory or non-directory portion of the name, respecting ?/ as the
> only separator.

These two functions are not supposed to be handed regexps anyway, even
on Unix.  For example, what's the filename part of "/foo\\(/a?\\)bar"?

  (file-name-nondirectory "/foo\\(/a?\\)bar") => "a?\\)bar"

Or how about this:

  (file-name-nondirectory "/foo[^/]*") => "]*"

This simply doesn't work, on any system.  Even in your example, you
cheated: you passed a substring of a regexp, to avoid the problems
with leading drive spec, which must be at the beginning of the file
name to work with these functions.

> > 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.
> 
> Parsing output of programs is something altogether different.

It's not different.  These functions are used all the time for parsing
file names, including those in output of other programs.

There are also users who use backslashes in their ~/.emacs files, when
they specify file names and programs.

> That is a completely different requirement and should be handled, naturally, by
> special-purpose code (i.e. at a different level) - code that knows just what to
> expect from those particular programs.

If you do this, you will flood the application sources with ugly
system-dependent conditions.  Hardly a good idea.

> What is the real requirement to support also ?\?

That it is used in DOS/Windows file names in many situations.

> "Seamless", indeed.  Putting special-case handling throughout the code doesn't
> make things seamless; it makes them quite seamy.

The special-case code has to be somewhere.  Having it at the current
low level in C, hidden from the Lisp programs, is the best we can do.

> The simple functions `file-name-directory' and `file-name-nondirectory' should
> be robust enough to just remove the non-directory and directory portion -
> always.

It does that today.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.