bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Drew Adams
Subject: bug#60819: 28.2; `ls-lisp.el' regression introduced in Emacs 26
Date: Sun, 15 Jan 2023 17:04:05 +0000

> > In all Emacs releases prior to Emacs 26, if you use command `dired'
> > with an input directory name that has wildcards and ends with a slash,
> > e.g. c:/foo/bar/*b*/, the command simply ignores the trailing slash and
> > correctly gives you a listing of all files and dirs in c:/foo/bar/
> > whose names contain a b character.
> >
> > Starting with Emacs 26, such input raises an error.  IMO it should not.
> >
> > Other than that, the error message is anyway inappropriate: "No files
> > matching regexp".
> 
> I fixed the message to say "No files matching wildcard" instead.
> 
> > In general, the character / in a glob pattern cannot be matched by a
> > wildcard.  E.g., Wikipedia says "Normally, the path separator character
> > (/ on Linux/Unix, MacOS, etc. or \ on Windows) will never be matched."
> > and Linux man page glob(7) says "A '/' in a pathname cannot be matched
> > by a '?' or '*' wildcard, or by a range like "[.-0]"."
> 
> This is incorrect.  A wildcard like "*b*/" should expand to the list
> of directories whose names match "*b*", whereas "*b*" should expand to
> the list of files _and_ directories with matching names.  This is how
> Dired behaves on Posix platforms (where such an expansion is done by
> the 'ls' program), and we want a similar behavior with ls-lisp.

Excellent.  That's in fact what I was naively expecting
or hoping for.

But googling for info about what such a glob pattern
should match, I couldn't find anything that supported
such an interpretation.  Could you maybe point me to a
source that covers this - so I can read more and point
others to it?  If you don't have the time to find that
then don't worry about it.  Thx.

> So I've now made ls-lisp on the emacs-29 branch behave like that: a
> wildcard that ends in a slash is expanded to the list of matching
> directories.  And with that, I'm closing this bug.

Sounds good.  Thx.






reply via email to

[Prev in Thread] Current Thread [Next in Thread]