GNU bug report logs -
#60819
28.2; `ls-lisp.el' regression introduced in Emacs 26
Previous Next
Reported by: Drew Adams <drew.adams <at> oracle.com>
Date: Sat, 14 Jan 2023 22:29:02 UTC
Severity: normal
Found in version 28.2
Done: Eli Zaretskii <eliz <at> gnu.org>
Bug is archived. No further changes may be made.
Full log
View this message in rfc822 format
[Message part 1 (text/plain, inline)]
Your bug report
#60819: 28.2; `ls-lisp.el' regression introduced in Emacs 26
which was filed against the emacs package, has been closed.
The explanation is attached below, along with your original report.
If you require more details, please reply to 60819 <at> debbugs.gnu.org.
--
60819: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=60819
GNU Bug Tracking System
Contact help-debbugs <at> gnu.org with problems
[Message part 2 (message/rfc822, inline)]
> From: Drew Adams <drew.adams <at> oracle.com>
> Date: Sat, 14 Jan 2023 22:28:36 +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.
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.
[Message part 3 (message/rfc822, inline)]
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". There's absolutely no regep involved. *b* is a glob
pattern, not a regexp - and so is *b*/, for that matter.
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]"."
I think the change in behavior (raising an error) is wrong. Emacs prior
to Emacs 26 was correct in ignoring a trailing slash in this context.
Please revert the code that introduced this regression.
In GNU Emacs 28.2 (build 2, x86_64-w64-mingw32)
of 2022-09-13 built on AVALON
Windowing system distributor 'Microsoft Corp.', version 10.0.19044
System Description: Microsoft Windows 10 Pro (v10.0.2009.19044.2364)
Configured using:
'configure --with-modules --without-dbus --with-native-compilation
--without-compress-install CFLAGS=-O2'
Configured features:
ACL GIF GMP GNUTLS HARFBUZZ JPEG JSON LCMS2 LIBXML2 MODULES NATIVE_COMP
NOTIFY W32NOTIFY PDUMPER PNG RSVG SOUND THREADS TIFF TOOLKIT_SCROLL_BARS
XPM ZLIB
(NATIVE_COMP present but libgccjit not available)
This bug report was last modified 1 year and 154 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.