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?
@rl_dane @amin @kabel42 @sotolf @thedoctor the less(1) manpage is full of lies.
The older one in MirBSD:
/pattern
Search forward in the file for the N-th line containing the pat-
tern. N defaults to 1. The pattern is a regular expression, as
recognized by ed(1). The search starts at the second line displayed
No, less(1) uses different REs than ed(1), which uses POSIX BRE.
The newer one in Debian:
/pattern
Search forward in the file for the N-th line containing the patā
tern. N defaults to 1. The pattern is a regular expression, as
recognized by the regular expression library supplied by your
system. The search starts at the first line displayed (but see
Just as big a lie, glibcās regexp (as documented by Linux man-pages) also does not support \< or \>.
@mirabilos @amin @kabel42 @sotolf @thedoctor
Really! I don't recall \< and \> ever not working for me.
@rl_dane @amin @kabel42 @sotolf @thedoctor then, my dear, youāre suffering from GNU extensions. (Probably. I still havenāt figured out where it came from. No manpage on my Debian I tried documents it, other than
grep(1).)@mirabilos @amin @kabel42 @sotolf @thedoctor
Hmm, I wonder if it would be different on Alpine Linux, as that's a relatively non-GNU distro.
@mirabilos @amin @kabel42 @sotolf @thedoctor
lol fair, sorry.