GNU bug report logs - #43375
26.1: file-directory-p returns t for empty string

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 43375 in the body.
You can then email your comments to 43375 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Boruch Baum <boruch_baum <at> gmx.com>
To: Emacs Bug Reporting <bug-gnu-emacs <at> gnu.org>
Subject: 26.1: file-directory-p returns t for empty string
Date: Sun, 13 Sep 2020 08:47:37 -0400

I was expecting the follow to return nil, but it returns t

  (file-directory-p "")


--
hkp://keys.gnupg.net
CA45 09B5 5351 7C11 A9D1  7286 0036 9E45 1595 8BC0

Message #8 received at 43375 <at> debbugs.gnu.org (full text, mbox):

From: Andreas Schwab <schwab <at> linux-m68k.org>
To: Boruch Baum <boruch_baum <at> gmx.com>
Cc: 43375 <at> debbugs.gnu.org
Subject: Re: bug#43375: 26.1: file-directory-p returns t for empty string
Date: Sun, 13 Sep 2020 15:06:02 +0200

On Sep 13 2020, Boruch Baum wrote:

> I was expecting the follow to return nil, but it returns t
>
>   (file-directory-p "")

This is not a bug, as Emacs always works with expanded and canonicalized
file names (the result of applying expand-file-name).

Andreas.

-- 
Andreas Schwab, schwab <at> linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

Message #13 received at 43375 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Andreas Schwab <schwab <at> linux-m68k.org>
Cc: Boruch Baum <boruch_baum <at> gmx.com>, 43375 <at> debbugs.gnu.org
Subject: Re: bug#43375: 26.1: file-directory-p returns t for empty string
Date: Sun, 13 Sep 2020 15:34:33 +0200

Andreas Schwab <schwab <at> linux-m68k.org> writes:

>> I was expecting the follow to return nil, but it returns t
>>
>>   (file-directory-p "")
>
> This is not a bug, as Emacs always works with expanded and canonicalized
> file names (the result of applying expand-file-name).

Yup.  It should be documented, though, so I've now mentioned this quirk
in the doc string in Emacs 28.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Message #20 received at 43375 <at> debbugs.gnu.org (full text, mbox):

From: Boruch Baum <boruch_baum <at> gmx.com>
To: Andreas Schwab <schwab <at> linux-m68k.org>
Cc: 43375 <at> debbugs.gnu.org
Subject: Re: bug#43375: 26.1: file-directory-p returns t for empty string
Date: Sun, 13 Sep 2020 10:39:43 -0400

On 2020-09-13 15:06, Andreas Schwab wrote:
> On Sep 13 2020, Boruch Baum wrote:
>
> > I was expecting the follow to return nil, but it returns t
> >
> >   (file-directory-p "")
>
> This is not a bug, as Emacs always works with expanded and canonicalized
> file names (the result of applying expand-file-name).

Then the docstring could be clearer and say "Return t if the expansion
of FILENAME names an existing directory" instead of simply the current
"Return t if FILENAME names an existing directory". Would that be an
acceptable change?

--
hkp://keys.gnupg.net
CA45 09B5 5351 7C11 A9D1  7286 0036 9E45 1595 8BC0

Message #23 received at 43375 <at> debbugs.gnu.org (full text, mbox):

From: Boruch Baum <boruch_baum <at> gmx.com>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: Andreas Schwab <schwab <at> linux-m68k.org>, 43375 <at> debbugs.gnu.org
Subject: Re: bug#43375: 26.1: file-directory-p returns t for empty string
Date: Sun, 13 Sep 2020 10:40:45 -0400

Thanks

On 2020-09-13 15:34, Lars Ingebrigtsen wrote:
> Andreas Schwab <schwab <at> linux-m68k.org> writes:
>
> > This is not a bug, as Emacs always works with expanded and canonicalized
> > file names (the result of applying expand-file-name).
>
> Yup.  It should be documented, though, so I've now mentioned this quirk
> in the doc string in Emacs 28.
>

--
hkp://keys.gnupg.net
CA45 09B5 5351 7C11 A9D1  7286 0036 9E45 1595 8BC0

Message #26 received at 43375 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Boruch Baum <boruch_baum <at> gmx.com>
Cc: schwab <at> linux-m68k.org, 43375 <at> debbugs.gnu.org
Subject: Re: bug#43375: 26.1: file-directory-p returns t for empty string
Date: Sun, 13 Sep 2020 18:01:51 +0300

> Date: Sun, 13 Sep 2020 10:39:43 -0400
> From: Boruch Baum <boruch_baum <at> gmx.com>
> Cc: 43375 <at> debbugs.gnu.org
> 
> > >   (file-directory-p "")
> >
> > This is not a bug, as Emacs always works with expanded and canonicalized
> > file names (the result of applying expand-file-name).
> 
> Then the docstring could be clearer and say "Return t if the expansion
> of FILENAME names an existing directory"

That's not a useful doc string, because "expansion of FILENAME" is not
well defined, and is not easy to describe.

I'm okay with making the doc string more clear, but let's please think
about a more useful amendment.  A doc string should help the user
understand what will/did happen, it shouldn't present puzzles.

Message #29 received at 43375 <at> debbugs.gnu.org (full text, mbox):

From: Andreas Schwab <schwab <at> linux-m68k.org>
To: Boruch Baum <boruch_baum <at> gmx.com>
Cc: 43375 <at> debbugs.gnu.org
Subject: Re: bug#43375: 26.1: file-directory-p returns t for empty string
Date: Sun, 13 Sep 2020 17:56:48 +0200

On Sep 13 2020, Boruch Baum wrote:

> Then the docstring could be clearer and say "Return t if the expansion
> of FILENAME names an existing directory" instead of simply the current
> "Return t if FILENAME names an existing directory". Would that be an
> acceptable change?

This is already documented in the Elisp manual:

       Many of the file functions take one or more arguments that are file
    names.  A file name is a string.  Most of these functions expand file
    name arguments using the function ‘expand-file-name’, so that ‘~’ is
    handled correctly, as are relative file names (including ‘../’ and the
    empty string).  *Note File Name Expansion::.

Andreas.

-- 
Andreas Schwab, schwab <at> linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

Message #32 received at 43375 <at> debbugs.gnu.org (full text, mbox):

From: Boruch Baum <boruch_baum <at> gmx.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: schwab <at> linux-m68k.org, 43375 <at> debbugs.gnu.org
Subject: Re: bug#43375: 26.1: file-directory-p returns t for empty string
Date: Sun, 13 Sep 2020 12:29:00 -0400

On 2020-09-13 18:01, Eli Zaretskii wrote:
> > Date: Sun, 13 Sep 2020 10:39:43 -0400
> > From: Boruch Baum <boruch_baum <at> gmx.com>
> > Cc: 43375 <at> debbugs.gnu.org
> >
> > > >   (file-directory-p "")
> > >
> > > This is not a bug, as Emacs always works with expanded and canonicalized
> > > file names (the result of applying expand-file-name).
> >
> > Then the docstring could be clearer and say "Return t if the expansion
> > of FILENAME names an existing directory"
>
> That's not a useful doc string, because "expansion of FILENAME" is not
> well defined, and is not easy to describe.
>
> I'm okay with making the doc string more clear, but let's please think
> about a more useful amendment.  A doc string should help the user
> understand what will/did happen, it shouldn't present puzzles.

How about:

  Return t if evaluating `expand-file-name' on FILENAME names an existing
  directory.

--
hkp://keys.gnupg.net
CA45 09B5 5351 7C11 A9D1  7286 0036 9E45 1595 8BC0

Message #35 received at 43375 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Boruch Baum <boruch_baum <at> gmx.com>
Cc: schwab <at> linux-m68k.org, 43375 <at> debbugs.gnu.org
Subject: Re: bug#43375: 26.1: file-directory-p returns t for empty string
Date: Sun, 13 Sep 2020 19:47:35 +0300

> Date: Sun, 13 Sep 2020 12:29:00 -0400
> From: Boruch Baum <boruch_baum <at> gmx.com>
> Cc: schwab <at> linux-m68k.org, 43375 <at> debbugs.gnu.org
> 
> > I'm okay with making the doc string more clear, but let's please think
> > about a more useful amendment.  A doc string should help the user
> > understand what will/did happen, it shouldn't present puzzles.
> 
> How about:
> 
>   Return t if evaluating `expand-file-name' on FILENAME names an existing
>   directory.

How does that help the reader predict what will happen in each and
every case without actually trying?

Anyway, I think this is a moot point, since Lars already fixed the doc
string to mention this special case, and the current text is clear
enough to my palate.

Previous Next

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