GNU bug report logs -
#27844
26.0.50; Dired w/ eshell-ls doesn't support wildcards in file name
Previous Next
Reported by: Tino Calancha <tino.calancha <at> gmail.com>
Date: Thu, 27 Jul 2017 03:28:01 UTC
Severity: minor
Found in version 26.0.50
Done: Tino Calancha <tino.calancha <at> gmail.com>
Bug is archived. No further changes may be made.
Full log
View this message in rfc822 format
> From: Tino Calancha <tino.calancha <at> gmail.com>
> Cc: 27844 <at> debbugs.gnu.org
> Date: Tue, 01 Aug 2017 12:00:39 +0900
>
> Eli Zaretskii <eliz <at> gnu.org> writes:
>
> >> From: Tino Calancha <tino.calancha <at> gmail.com>
> >> Date: Thu, 27 Jul 2017 18:23:08 +0900
> >>
> >> `eshell-extended-glob' returns a list of matches on success, otherwise
> >> it returns FILE; if no match i think we should signal an error.
> >
> > Whether this should be an error or just FILE is a matter of personal
> > preferences, I think. Some shells behave this way, others the other
> > way. So either we should leave your original patch as it was, or
> > introduce a defcustom to produce an error if the user so wants.
> Indeed such defcustom already does exist: eshell-error-if-no-glob
> (default to nil).
> You can see at the end of `eshell-extended-glob':
> (if eshell-error-if-no-glob
> (error "No matches found: %s" glob)
> glob)
I'm confused: I wasn't commenting on what eshell-extended-glob does, I
was commenting about your code:
+ (let ((matches (eshell-extended-glob file)))
+ (if (consp matches)
+ (mapcar #'file-relative-name matches)
+ (user-error (format "%s: No files matching wildcard" file))))
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
If eshell-extended-glob already signals an error when it's TRT, why do
you need to signal an error if Eshell doesn't? What am I missing?
Thanks.
This bug report was last modified 7 years and 296 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.