HackerReposA FIELD GUIDE TO OPEN SOURCE
ProSponsor the shelf♧ 0
← Back to top all-time
p-ranav
hypergrep
C++2023–2023
p-ranav / hypergrep

hypergrep

Recursively search directories for a regex pattern

5Distinct people
5Mentions
0Explicit recommenders
249GitHub stars
REPOSITORY AT A GLANCE

What to know before exploring

What it is

Recursively search directories for a regex pattern

GitHub

Where it is used

No documented product use has been verified yet.

What people are saying

No recommendation phrase was found in the indexed comments.

No classified warning is attached to this page. Read the discussions before treating silence as approval.

Also in these discussions

No other repository is repeatedly linked in the same discussions.

This week on Hacker News

Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 1:49:46 PM UTC.

No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.

Mentions over time

HN mentions by week5 dated mentions

Observed mentions: 2023-06-08 23:35:12 UTC to 2023-12-31 14:37:19 UTC. Weeks start Monday, UTC.

012342023-06-05 00:00:00 UTC to 2023-06-12 00:00:00 UTC (exclusive): 1 mentions; 1 submissions, 0 commentsJun 52023-06-12 00:00:00 UTC to 2023-06-19 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2023-06-19 00:00:00 UTC to 2023-06-26 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2023-06-26 00:00:00 UTC to 2023-07-03 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2023-07-03 00:00:00 UTC to 2023-07-10 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2023-07-10 00:00:00 UTC to 2023-07-17 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2023-07-17 00:00:00 UTC to 2023-07-24 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2023-07-24 00:00:00 UTC to 2023-07-31 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2023-07-31 00:00:00 UTC to 2023-08-07 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2023-08-07 00:00:00 UTC to 2023-08-14 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2023-08-14 00:00:00 UTC to 2023-08-21 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2023-08-21 00:00:00 UTC to 2023-08-28 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2023-08-28 00:00:00 UTC to 2023-09-04 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2023-09-04 00:00:00 UTC to 2023-09-11 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2023-09-11 00:00:00 UTC to 2023-09-18 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 commentsSep 112023-09-18 00:00:00 UTC to 2023-09-25 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2023-09-25 00:00:00 UTC to 2023-10-02 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2023-10-02 00:00:00 UTC to 2023-10-09 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2023-10-09 00:00:00 UTC to 2023-10-16 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2023-10-16 00:00:00 UTC to 2023-10-23 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2023-10-23 00:00:00 UTC to 2023-10-30 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2023-10-30 00:00:00 UTC to 2023-11-06 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2023-11-06 00:00:00 UTC to 2023-11-13 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2023-11-13 00:00:00 UTC to 2023-11-20 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2023-11-20 00:00:00 UTC to 2023-11-27 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2023-11-27 00:00:00 UTC to 2023-12-04 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2023-12-04 00:00:00 UTC to 2023-12-11 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2023-12-11 00:00:00 UTC to 2023-12-18 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2023-12-18 00:00:00 UTC to 2023-12-25 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2023-12-25 00:00:00 UTC to 2024-01-01 00:00:00 UTC (exclusive): 4 mentions; 0 submissions, 4 commentsDec 25

Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.

View mention counts and date ranges
UTC ranges include their start and exclude their end. Select a period to filter the source evidence.
PeriodStart (UTC)End (exclusive, UTC)MentionsSubmissionsComments
Jun 52023-06-05 00:00:00 UTC2023-06-12 00:00:00 UTC110
Jun 122023-06-12 00:00:00 UTC2023-06-19 00:00:00 UTC000
Jun 192023-06-19 00:00:00 UTC2023-06-26 00:00:00 UTC000
Jun 262023-06-26 00:00:00 UTC2023-07-03 00:00:00 UTC000
Jul 32023-07-03 00:00:00 UTC2023-07-10 00:00:00 UTC000
Jul 102023-07-10 00:00:00 UTC2023-07-17 00:00:00 UTC000
Jul 172023-07-17 00:00:00 UTC2023-07-24 00:00:00 UTC000
Jul 242023-07-24 00:00:00 UTC2023-07-31 00:00:00 UTC000
Jul 312023-07-31 00:00:00 UTC2023-08-07 00:00:00 UTC000
Aug 72023-08-07 00:00:00 UTC2023-08-14 00:00:00 UTC000
Aug 142023-08-14 00:00:00 UTC2023-08-21 00:00:00 UTC000
Aug 212023-08-21 00:00:00 UTC2023-08-28 00:00:00 UTC000
Aug 282023-08-28 00:00:00 UTC2023-09-04 00:00:00 UTC000
Sep 42023-09-04 00:00:00 UTC2023-09-11 00:00:00 UTC000
Sep 112023-09-11 00:00:00 UTC2023-09-18 00:00:00 UTC000
Sep 182023-09-18 00:00:00 UTC2023-09-25 00:00:00 UTC000
Sep 252023-09-25 00:00:00 UTC2023-10-02 00:00:00 UTC000
Oct 22023-10-02 00:00:00 UTC2023-10-09 00:00:00 UTC000
Oct 92023-10-09 00:00:00 UTC2023-10-16 00:00:00 UTC000
Oct 162023-10-16 00:00:00 UTC2023-10-23 00:00:00 UTC000
Oct 232023-10-23 00:00:00 UTC2023-10-30 00:00:00 UTC000
Oct 302023-10-30 00:00:00 UTC2023-11-06 00:00:00 UTC000
Nov 62023-11-06 00:00:00 UTC2023-11-13 00:00:00 UTC000
Nov 132023-11-13 00:00:00 UTC2023-11-20 00:00:00 UTC000
Nov 202023-11-20 00:00:00 UTC2023-11-27 00:00:00 UTC000
Nov 272023-11-27 00:00:00 UTC2023-12-04 00:00:00 UTC000
Dec 42023-12-04 00:00:00 UTC2023-12-11 00:00:00 UTC000
Dec 112023-12-11 00:00:00 UTC2023-12-18 00:00:00 UTC000
Dec 182023-12-18 00:00:00 UTC2023-12-25 00:00:00 UTC000
Dec 252023-12-25 00:00:00 UTC2024-01-01 00:00:00 UTC404

What Hacker News says

5 sources
I don't disagree. It's why I brought this up. It's tricky to use Hyperscan, as-is, as a regex engine in a grep tool for these reasons. I don't mean to claim it is impossible, but there are non-trivial issues you'll need to solve. It's hard to learn too much from hypergrep. It still has some rough spots: $ hgrep -o 'foo.*bar' foobarbar.txt foobarbar.txt 1:[Omitted long line with 1 matches] $ hgrep -M0 -o 'foo.*bar' foobarbar.txt Too few arguments For more information try --help $ hgrep -M 0 -o 'foo.*bar' foobarbar.txt foobarbar.txt 1:[Omitted long line with 1 matches] $ hgrep -M 0 'foo.*bar' foobarbar.txt foobarbar.txt 1:[Omitted long line with 1 matches] $ hgrep -M0 'foo.*bar' foobarbar.txt terminate called after throwing an instance of 'std::invalid_argument' what(): patt
Read the rest
ern not found zsh: IOT instruction (core dumped) hgrep -M0 'foo.*bar' foobarbar.txt Another issue with Hyperscan is that if you enable HS_FLAG_UTF8[1], which hypergrep does[2,3], and then search invalid UTF-8, then the result is UB. > This flag instructs Hyperscan to treat the pattern as a sequence of UTF-8 characters. The results of scanning invalid UTF-8 sequences with a Hyperscan library that has been compiled with one or more patterns using this flag are undefined. That's another issue you'll need to grapple with if you use Hyperscan. PCRE2 used to have this issue[4], but they've since defined the semantics of searching invalid UTF-8 with Unicode mode enabled. ripgrep 14 uses that new mode, but I haven't updated that FAQ answer yet. Hyperscan isn't alone. Many regex engines do not support searching arbitrary byte sequences[5]. And this is why many/most regex engines are awkward to use in a fast grep implementation. Because you really do not want your grep to fall over when it comes across invalid UTF-8. And the overhead of doing UTF-8 checking in the first place (and perhaps let you just skip over lines that contain invalid UTF-8) would make it difficult to be competitive in performance. It also inhibits its usage in OSINT work. [1]: https://intel.github.io/hyperscan/dev-reference/api_files.ht... [2]: https://github.com/p-ranav/hypergrep/blob/ee85b713aa84e0050a... [3]: https://github.com/p-ranav/hypergrep/blob/ee85b713aa84e0050a... [4]: https://github.com/BurntSushi/ripgrep/blob/master/FAQ.md#why... [5]: https://github.com/BurntSushi/rebar/blob/96c6779b7e1cdd850b8...
In Ugrep – a more powerful, fast, user-friendly, compatible grep
It might be the intended behavior of Hyperscan but it really feels like a bug in Hypergrep to report the matches like this - you cannot report a match which doesn't fully match the regex... I also wonder if there's a performance issue when matching a really long line because Hyperscan is not greedy and will ping back to Hypergrep for every sub match. I guessing this is the reason for those shenanigans in the callback [0]. $ python -c 'print("foo" + "bar" * 3000)' | hg -o 'foo.*bar' [0] https://github.com/p-ranav/hypergrep/blob/ee85b713aa84e0050a...
In Ugrep – a more powerful, fast, user-friendly, compatible grep
Haven't benchmarked *grep implementations, but assuming those are just CLI wrappers around RegEx libraries, I'd expect the RegEx benchmarks to be broader and more representative. There, hyperscan is generally the king, which means hypergrep numbers are likely accurate: https://github.com/p-ranav/hypergrep?tab=readme-ov-file#dire... Disclaimer: I rarely use any *grep utilities, but often implement string libraries.
In Ugrep – a more powerful, fast, user-friendly, compatible grep

MAKE YOURSELF AT HOME

A few shortcuts

/
Search the collection
?
Open this guide
Esc
Close dialogs and navigation

Your saved repositories and interests stay in this browser.