R.L. Dane 
🍵 
File this under #shell #functions I should have written years ago:
function grepc {
#Do a grep -c, but skipping files with no results
grep -c "$@" |grep -v ':0$'
}
Amin, minor deity of the legume realmOh, didn't know about -c. I usually just pipe to wc -l I guess.
-c, -l, -h, -H, and -q are my favorite #grep flags. :D
Huh, that almost became a [Marcel Duchamp] reference. 😅
I just use -v and -E
sotolf
thedoctor...and bash instead of zsh
...and grep/awk/sed instead of jq
...and firefox instead of chrome
...and the fediverse instead of facebook
Face it... I'm an unpopular-opinion neckbeard level boss. XD
cc: @mirabilos
@thedoctor @rl_dane @amin @mirabilos At least bash and zsh is comparable to grep ripgrep, as zsh is just a strictly better bash ;)
@sotolf @thedoctor @rl_dane @mirabilos
Mm, not really though? ripgrep is meant for bulk grepping of files
@amin @thedoctor @rl_dane @mirabilos I think I had it installed, I just never remembered to use it :p
@sotolf @thedoctor @rl_dane @mirabilos
I mostly just use it to run rg TODO and see all the spots in a codebase I marked as still needing work.
@amin @sotolf @thedoctor @mirabilos
Why is ripgrep better than just grep -R?
kabel42@rl_dane @amin @sotolf @thedoctor @mirabilos it's somehow a lot faster if you want to grep a few GiB of code, like 15 minutes to 30 seconds
@kabel42 @amin @sotolf @thedoctor @mirabilos
Interesting! I wonder what kind of algorithmic optimizations (as opposed to compiler optimizations) they're using to do that, and if regular (GNU/BSD) grep could do the same.
Because I'll wear clown shoes and a tutu before changing to a "rewrite the world in rust!" utility 😂
@rl_dane @amin @sotolf @thedoctor @mirabilos From what little i have read, some assumptions about what you are greping and different defaults. Doing the same in existing grep would probably break compatibility.
mirabilos@kabel42 @rl_dane @amin @sotolf @thedoctor eww, it’s not even a drop-in then…
(For not-a-drop-in, I found pcregrep interesting. Sadly, Debian recently dropped it, but in the versions which don’t have pcregrep any more, you can use grep -P for many use cases. pcre2grep is not a drop-in for pcregrep either…)
@mirabilos @kabel42 @amin @sotolf @thedoctor
I was a total PCRE stan in the olden days, but I've steered more towards regular extended regexp for compatibility. I do miss \d, \w and \s, though. [[:space:]] feels so clumsy to type and use several times in a regex, I'll sometimes put a sp="[[:space:]]" line at the start of a script, and you'll see several invocations of "${sp}" in my regex strings.
But again... compatibility. ;)
Is there a big difference between (GNU) grep -P and pcregrep? I hadn't heard of that utility before.
@amin @kabel42 @rl_dane @sotolf @thedoctor I never used \d and the likes, always felt them much too complicated. I almost never use POSIX character classes (besides the BSD [[:<:]] and [[:>:]]), rather I just hit [ tab space ] quickly.
GNU grep -P does a PCRE grep, it doesn’t support all of the extra flags of pcregrep though, and before the version in IIRC trixie was very broken.
@mirabilos @amin @kabel42 @sotolf @thedoctor
is [[:<:]] and [[:>:]] the same as \< and \>?
@rl_dane @amin @kabel42 @sotolf @thedoctor obviously not, because it’s written differently ;)
re_format(7) knows:
There are two special cases** of bracket expressions: the bracket expres-
sions '[[:<:]]' and '[[:>:]]' match the null string at the beginning and
end of a word, respectively. A word is defined as a sequence of charac-
ters starting and ending with a word character which is neither preceded
nor followed by word characters. A word character is an alnum character
(as defined by ctype(3)) or an underscore. This is an extension, compati-
ble with but not specified by POSIX, and should be used with caution in
software intended to be portable to other systems.
(as for the mark:)
POSIX leaves some aspects of RE syntax and semantics open; '**' marks de-
cisions on these aspects that may not be fully portable to other POSIX
implementations.
The definition for \< / \> differs between less, perlre, pcre, … I believe, but they all are somewhat simiar.
@rl_dane @amin @kabel42 @sotolf @thedoctor perlre(1) actually has…
A word boundary ("\b") is a spot between two characters that
has a "\w" on one side of it and a "\W" on the other side of
it (in either order), counting the imaginary characters off
the beginning and end of the string as matching a "\W".
… so the \< probably comes from less(1)?
… hm, no. But, where then?
@mirabilos @amin @kabel42 @sotolf @thedoctor
I used to use \b a lot, but \< and \> are just as easy to use, and POSIX. ;)
\w is nice, though. I think the closest POSIX one is [[:graph:]]? (Not super close, though)
@rl_dane @amin @kabel42 @sotolf @thedoctor \< and \> are not POSIX.
perlre(1) \w is identical to POSIX [a-zA-Z0-9_] in the C locale, so [[:alnum:]_] if you have support for POSIX character classes.
@mirabilos @amin @kabel42 @sotolf @thedoctor
Ah, yes. [[:alnum:]] was the one I was thinking of.
@mirabilos @amin @kabel42 @sotolf @thedoctor
Waiiiiit, what does the underscore before the second bracket do? I've never seen that before.
No mention of it in RE_FORMAT(7) on FreeBSD.
@rl_dane @amin @kabel42 @sotolf @thedoctor the exact same thing as the underscore in
[a-zA-Z0-9_], and I’d be surprised if the FreeBSD manpage would not document it
@kabel42 @mirabilos @amin @sotolf @thedoctor
Doctor Strangepattern or: How I Learned to Stop Worrying and Love the Write-Once-Read-Never Nature of Regexp
@mirabilos @kabel42 @amin @sotolf @thedoctor
I think it's like almost any terse "programming" language where it takes some time to find the same neural pattern in your own head that produced it, so you can "remember" what you were doing. ^___^
In the past, I have literally used shell loops to construct regexp variables on the fly, rather than having completely incomprehensible "line noise" regexps. 😄
@rl_dane @kabel42 @amin @sotolf @thedoctor remember though that ksh extglobs are special at parse time, so you cannot do e.g.
foo='@(0|[1-9]*([0-9]))'; [[ $1 = $foo ]], you have to use eval (eurghs, best to avoid, especially in functions and loops due to the hard parse overhead each time)