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

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

[Boruch Baum]

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

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

[Andreas Schwab]

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@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

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

[Lars Ingebrigtsen]

Andreas Schwab <schwab@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

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

[Boruch Baum]

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

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

[Boruch Baum]

Thanks

On 2020-09-13 15:34, Lars Ingebrigtsen wrote:
> Andreas Schwab <schwab@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

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

[Eli Zaretskii]

> Date: Sun, 13 Sep 2020 10:39:43 -0400
> From: Boruch Baum <boruch_baum@gmx.com>
> Cc: 43375@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.

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

[Andreas Schwab]

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@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

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

[Boruch Baum]

On 2020-09-13 18:01, Eli Zaretskii wrote:
> > Date: Sun, 13 Sep 2020 10:39:43 -0400
> > From: Boruch Baum <boruch_baum@gmx.com>
> > Cc: 43375@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

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

[Eli Zaretskii]

> Date: Sun, 13 Sep 2020 12:29:00 -0400
> From: Boruch Baum <boruch_baum@gmx.com>
> Cc: schwab@linux-m68k.org, 43375@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.