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

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

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



Reply | Threaded
Open this post in threaded view
|

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

Andreas Schwab-2
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, [hidden email]
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."



Reply | Threaded
Open this post in threaded view
|

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



Reply | Threaded
Open this post in threaded view
|

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

Boruch Baum
In reply to this post by Andreas Schwab-2
Thanks

On 2020-09-13 15:34, Lars Ingebrigtsen wrote:
> Andreas Schwab <[hidden email]> 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



Reply | Threaded
Open this post in threaded view
|

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

Eli Zaretskii
In reply to this post by Boruch Baum
> Date: Sun, 13 Sep 2020 10:39:43 -0400
> From: Boruch Baum <[hidden email]>
> Cc: [hidden email]
>
> > >   (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.



Reply | Threaded
Open this post in threaded view
|

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

Andreas Schwab-2
In reply to this post by Boruch Baum
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, [hidden email]
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."



Reply | Threaded
Open this post in threaded view
|

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

Boruch Baum
In reply to this post by Eli Zaretskii
On 2020-09-13 18:01, Eli Zaretskii wrote:

> > Date: Sun, 13 Sep 2020 10:39:43 -0400
> > From: Boruch Baum <[hidden email]>
> > Cc: [hidden email]
> >
> > > >   (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



Reply | Threaded
Open this post in threaded view
|

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 <[hidden email]>
> Cc: [hidden email], [hidden email]
>
> > 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.