GNU bug report logs -
#37753
wish for glob(7)-like matcher
Previous Next
To reply to this bug, email your comments to 37753 AT debbugs.gnu.org.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-grep <at> gnu.org
:
bug#37753
; Package
grep
.
(Tue, 15 Oct 2019 01:44:01 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
"Trent W. Buck" <trentbuck <at> gmail.com>
:
New bug report received and forwarded. Copy sent to
bug-grep <at> gnu.org
.
(Tue, 15 Oct 2019 01:44:01 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
Package: grep
Version: 2.20-4
Severity: wishlist
Tags: upstream
This bug was originally reported as
https://bugs.debian.org/813356
I am attempting to upstream it into bugs.gnu.org.
PS: nowadays I also know to mention fnmatch(3).
On Mon, 01 Feb 2016 18:19:06 +1100 "Trent W. Buck" <trentbuck <at> gmail.com> wrote:
> Sometimes I want to match globs instead of regexps.
> glob(7) explicitly says:
> "they match filenames, rather than text"
> I don't see why globs shouldn't be used for text.
>
>
> In bash this is ugly and *SLOW*, e.g.
>
> # Print log lines that match no "whitelisted" patterns.
> while read -r line
> do
> if ! [[ line = glob1 || line = glob2 || ... ]]
> then echo "$line"
> fi
> done <log
>
> instead of
>
> grep --basic-glob -vf whitelist log
>
>
> GNU grep already has options for fixed strings (-F),
> and BRE, ERE and PCRE. Can we have one for glob(7)?
>
> AFAICT nobody has asked for this before; this surprises me,
> because it "feels" like it should be easy to implement.
>
> Am I wrong?
>
> Is there a good reason to WONTFIX this?
>
>
>
> I asked my peers and the only real counterargument I got was
> "just learn regexps, you'll need them eventually".
>
> For my use case, I think globs would be more readable (esp. not having
> to escape dots and parens), and easier to teach to non-technical staff.
> (I haven't trialled it yet, because I don't have a globber that's as
> fast as GNU grep is for regexps.)
>
>
> PS: I'd have directly reported this upstream,
> but https://sv.gnu.org/bugs/?group=grep says I must be a "project member",
> and I'm not.
Information forwarded
to
bug-grep <at> gnu.org
:
bug#37753
; Package
grep
.
(Wed, 13 Nov 2019 04:24:01 GMT)
Full text and
rfc822 format available.
Message #8 received at 37753 <at> debbugs.gnu.org (full text, mbox):
Hello, I know I've wanted this feature before, if for nothing else an easy
way to test various glob patterns against various inputs without having to
create a bunch of files in the filesystem.
Thanks
Information forwarded
to
bug-grep <at> gnu.org
:
bug#37753
; Package
grep
.
(Wed, 13 Nov 2019 18:06:02 GMT)
Full text and
rfc822 format available.
Message #11 received at submit <at> debbugs.gnu.org (full text, mbox):
2019-10-15 12:43:14 +1100, Trent W. Buck:
[...]
> > GNU grep already has options for fixed strings (-F),
> > and BRE, ERE and PCRE. Can we have one for glob(7)?
> >
> > AFAICT nobody has asked for this before; this surprises me,
> > because it "feels" like it should be easy to implement.
> >
> > Am I wrong?
[...]
For the record, ast-open's "grep" has
-K, --ksh-regexp
ksh(1) extended file match patterns.
That's ksh93 wildcards, a superset of bash -O extglob ones
(themselves shaped after ksh88's globs) with same feature level
as regexps.
$ echo abcde | ast-grep -Ko '?c?'
bcd
You can always define a POSIX shell function like:
fnmatch() (
pattern=${1?}; shift
cat -- "$@" | while IFS= read -r line || [ -n "$line" ]; do
case $line in ($pattern) printf '%s\n' "$line"
done
)
(though that will be very slow, especially with shells that
don't have "printf" or "[" builtin; and except in zsh, it won't
work properly with input containing NUL bytes).
Note that there is some variation in wildcard syntax from one
shell to the next and one or from one fnmatch() to the next
(though they generally support the minimum POSIX set at least).
There's also the question of whether you'd want to consider \ as
an escape operator (again YMMV depending on the shell for that
fnmatch() function above).
--
Stephane
This bug report was last modified 4 years and 187 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.