bug#60819: 28.2; `ls-lisp.el' regression introduced in Emacs 26

[Drew Adams]

(Restoring the bug-thread removed from cc.)

> >> >From OpenBSD's glob(7) manpage [1],
> >>  Note that when matching a pathname, the path separator ‘/’, is not
> >>  matched by a ‘?’, or ‘*’, character or by a “[..]” sequence. Thus,
> >>  /usr/*/*/X11 would match /usr/X11R6/lib/X11 and
> >>  /usr/X11R6/include/X11 while /usr/*/X11 would not match
> >>  either. Likewise, /usr/*/bin would match /usr/local/bin but not
> >>  /usr/bin.
> >
> > Thanks, but that's not the issue at hand.  What Drew wanted to see was
> > an explicit wording to the effect that a trailing slash makes the
> > wildcard match only directories.
> 
> Doesn't it follow from the quoted text?
> If * doesn't match a /, then it can't match a directory.  / is not a
> valid character in a filename so dir*/ would only match directories that
> starts with `dir'.

That it follows wasn't, and isn't, obvious to me.
(And I cited similar text from other sources, so
clearly I'd read such descriptions.)

> so dir*/ would only match directories that
  ^^
> starts with `dir'.

"So"?  I don't see how that follows.  Why would
one suppose that it matches directory names at
all?  The glob doc says that `/' in a glob
pattern delimits pattern segments that match
file-name components - nothing more.  What text
says that a directory name that matches a glob
pattern ends with `/'?

*b*a matches file names that include `a' after
what *b* matches.  But `a' is a char that _can_
be matched by a glob pattern, including by a
wildcard.

Can `/'?  It can't match a wildcard, at least.
But can a literal `/' in a glob pattern match a
`/' that's in a file-name component itself (i.e.,
in the text between the directory separators,
which for Emacs are `/')?  Is such a component
even possible?

I suppose so, but to include `/' in a file-name
component that char would have had to be escaped
when creating the file whose name includes it.
Or some other, equivalent means would have had
to be employed.

I'm no expert on whether this is even possible,
or how one might do it (including within Emacs,
and `touch' apparently won't do it).  But let's
assume you _can_ do it: somehow embed `/' in a
file-name component, so it's _part_ of the file
name.  And let's assume you can even do that
at the end of the file name: have the last
file-name component have `/' as its last char.

In such a (rare) case I can see how *b*/ would
match a file name whose last char is `/'.  To
me, that's the only way in which the text you
cited (and the similar text I cited) could be
saying that a glob pattern with `/' chars in
it could actually match those chars against '/'
chars embedded in a file name itself.

But I don't think this rare possibility (if it
is a possibility) is what Eli's talking about.
I don't think he's talking about `/' characters
embedded in a file name.

A `/' at the end of an Emacs absolute file name
isn't within any file-name component (unless -
see previous paragraphs, for a hypothetical
possibility).

I think Eli is saying that for Emacs such a `/'
is part of a directory's file name, i.e., what
(elisp) `Directory Names" calls the “directory
file name”.  I understand this to mean what
function `file-name-as-directory' returns: the
file name considered as directory, which Emacs
writes with a `/' at the end.  (Per POSIX etc.)

To me it wasn't obvious that a glob pattern that
ends with `/' imposes a `file-name-as-directory'
interpretation on candidate matches (but that's
exactly what I wanted Emacs's handling of globs
to do).  I do think it would help for the doc to
point this out, if that's what's meant.  I do.

But I understand that for you (and Eli?) this is
considered obvious.  I'll just say that if so,
then maybe it's a bit odd that the until-now
bugged behavior (existing since Day One or at
least as far back as Emacs 20): (1) existed and
(2) hadn't been reported as a bug.  Those facts
suggest to me that this hasn't been obvious at
all.  Apparently the ls-lisp code never thought
to implement it, and no one noticed that, or at
least never thought it was a bug.

So I still think some mention in the doc would
help.  But in any case, I'm happy to see the
bug fixed, including the faulty error msg.

That's really what I cared about.  And I'm glad
to have learned a thing or two (though I wonder
about the possibility of embedding `/' chars in
file-name components).