Ugrep – a more powerful, fast, user-friendly, compatible grep

Original Article ↗ Hacker News Discussion ↗

A new grep alternative, ugrep, is being weighed against established tools like ripgrep and GNU grep on speed, feature set, and compatibility. Commenters highlight ugrep’s strengths—built‑in TUI, fuzzy matching, archive and index support, and GNU‑style options—while questioning its benchmark claims and pointing out edge‑case incompatibilities with GNU grep and locale handling. Much of the debate centers on trade‑offs between raw performance, regex semantics, binary size, portability, and the practicality of adopting nonstandard tools in environments where plain grep is always available.

Performance comparisons (ugrep vs ripgrep & others)

  • ugrep’s README claims it is faster than GNU grep, ag, ack, sift, and usually faster than ripgrep.
  • Some commenters are skeptical of ugrep’s self-published benchmarks and prefer independent comparisons.
  • A detailed subthread dives into benchmark methodology:
    • Grep-like tools are line-oriented and can add optimizations beyond a raw regex library.
    • Memory use numbers can be misleading due to mmap inflating RSS; disabling mmap shows much smaller real heap usage.
    • Performance depends heavily on file size, match frequency, and pattern shape (e.g., bounded repeats like .{100} can stress many regex engines).
  • Hypergrep/Hyperscan are discussed as very fast alternatives, especially for many patterns, but with tricky match semantics and build/portability issues.

Features and differences vs ripgrep/grep

  • ugrep is available in Debian-based repos and aims to be GNU grep–compatible, including options and behavior, though users find concrete incompatibilities (e.g., locale/character class handling).
  • Notable ugrep features praised:
    • Built-in pager with search-in-results (cross-platform).
    • Fuzzy matching.
    • Recursive archive search that respects archive structure.
    • Interactive TUI and regex-building interface.
  • Some still prefer ripgrep for: mature tooling, familiarity, speed that is “fast enough,” and strong defaults.

Regex syntax & word boundaries

  • Debate over POSIX BRE/ERE vs PCRE-style syntax.
  • Some users stick to classic grep syntax; others find it a reason to avoid grep.
  • ripgrep’s default regex is similar to grep -E, with linear-time guarantees (no backrefs/lookaround).
  • There is discussion of word boundaries (\b, \<, \>) and Unicode “word” definitions differing across engines.

Paging, TUI, and “user friendliness”

  • Built-in pager in ugrep is a selling point for some, especially on Windows; others see it as an antifeature and prefer explicit pipes to less/other pagers.
  • Several ripgrep-based TUIs and fzf integrations are mentioned as alternatives.
  • “User-friendly” is interpreted by some as the presence of an interactive TUI rather than traditional CLI ergonomics.

Indexing and large repositories

  • ugrep’s n‑gram indexer exists but is reported as slow (e.g., indexing the Linux kernel tree much slower than csearch’s cindex).
  • It creates per-directory index files and is labeled beta; reindexing is incremental.

Configuration, standards, and portability

  • ripgrep uses an env-var-based config path rather than XDG; some find this simpler, others dislike the divergence.
  • Concerns about XDG applicability on Windows/macOS are raised.
  • Some users won’t adopt non-standard greps because they rely on plain grep being present on all systems, especially locked-down or customer machines.

Other tools & ecosystem notes

  • Hypergrep, grab, hound, csearch, ripgrep-all, fzf, and various pagers (less, bat, others) are brought up.
  • Thread highlights that many modern greps are “good enough,” and choice often comes down to minor feature/preferences rather than clear dominance.