[Top][All Lists]

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

bug#37753: wish for glob(7)-like matcher

From: Trent W. Buck
Subject: bug#37753: wish for glob(7)-like matcher
Date: Tue, 15 Oct 2019 12:43:14 +1100
User-agent: Mutt/1.10.1 (2018-07-13)

Package: grep
Version: 2.20-4
Severity: wishlist
Tags: upstream

This bug was originally reported as

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" <address@hidden> 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.

reply via email to

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