Re: Directory names versus directory file names

> From: Sean Whitton <[email protected]>
> Cc: Spencer Baugh <[email protected]>
> Date: Thu, 27 Aug 2026 11:15:13 +0100
> 
> Terminology I'll use:
> - a _directory name_ is one that on Unix always _has_ a trailing slash
> - a _directory file name_ is one that on Unix _lacks_ a trailing slash
> - "a string naming a directory" is deliberately ambiguous.
> 
> This is my understanding of how the Lisp programmer should deal with
> these:
> 
>     (1) When Lisp code knows that a string names a directory, it should
>     ensure that it ends in a trailing slash.  I.e., functions should
>     pass and return known directories as strings with trailing slashes.

I don't think I agree.

>     The exceptions are:
>     - Code dealing with only file names, and not files and directories
>       themselves.
>     - When the code couldn't know whether the string names a directory
>       or a file without making additional system calls, which can mean a
>       significant performance hit.

See, I think the cases where one of these (or other relevant)
considerations apply are too many to reliably expect what you seem to
want.  More importantly, they cannot be known in advance by Lisp
programmers in many cases.

>     (2) Code should usually be prepared to deal with both directory
>     names and directory file names as much as is practical because lots
>     of user (and core and package) code and scripting doesn't
>     consistently append trailing slashes.

Yes.

>     - directory-files returns directory file names instead of directory
>       names.  But that's correct because determining which items name
>       directories would require additional system calls.

Not strictly true because on most systems the file's type is reported
by 'readdir'.

More generally, I don't understand why significant design decisions
should depend on implementation details of the low-level syscalls we
use.  How can a Lisp programmer know whether a given primitive returns
directories with or without the trailing slash, except by reading the
source and finding out which libc functions we use to implement the
primitives?

>     - directory-files-recursively also returns directory file names
>       instead of directory names if INCLUDE-DIRECTORIES is non-nil.
>       But that's buggy: it should always know when an item names a
>       directory, so it can append the trailing slash.

Again, such conjectures should not be required.  Either we always
require directory names to be returned with a slash, or we live with
the current chaos.

> But am I correct?  Spencer pointed out to me an interesting counter
> argument: avoiding appending a trailing slash until and unless you need
> to do something inside a directory could catch certain errors before
> they happen.
> 
> For example, if you want to pass a directory to some shell commands
> (like VC does), you don't need a trailing slash.

This is also inaccurate: for example, some Coreutils commands operate
differently depending on whether a file name does or doesn't end in a
slash.

> But then if the directory file name ended up as the second argument
> to `rename-file', there'd be an error instead of accidentally moving
> files inside the directory.

Yes, and 'mv' behaves the same.

> - should VC change in the sort of way suggested here?
>   Mainly this means that it will strip the trailing slash from
>   default-directory before adding it to a fileset.

I see no reason to do that, but maybe I'm missing something.