Ugrep – 一个更强大、更快、对用户更友好、兼容的 grep

原文 ↗ Hacker News 讨论 ↗

一个新的 grep 替代品 ugrep 正在与 ripgrep 和 GNU grep 等成熟工具进行速度、功能集和兼容性方面的比较。评论者指出 ugrep 的优点——内置 TUI、模糊匹配、归档与索引支持，以及 GNU 风格选项——同时也质疑其基准测试声明，并指出它在某些边缘场景下与 GNU grep 和 locale 处理存在不兼容。讨论的大部分内容围绕原始性能、正则语义、二进制大小、可移植性，以及在普通 grep 始终可用的环境中采用非标准工具的实际可行性展开。

性能对比（ugrep vs ripgrep 等）

  • ugrep 的 README 声称它比 GNU grep、ag、ack、sift 更快，而且通常也比 ripgrep 更快。
  • 一些评论者对 ugrep 自行发布的基准测试持怀疑态度，更偏好独立对比。
  • 一个详细的子线程深入讨论了基准方法：
    • 类 grep 工具是按行工作的，并且可以在原始正则库之外加入额外优化。
    • 由于 mmap 会抬高 RSS，内存使用数据可能具有误导性；禁用 mmap 后，实际堆内存使用要小得多。
    • 性能在很大程度上取决于文件大小、匹配频率以及模式形状（例如，像 .{100} 这样的有界重复会给许多正则引擎带来压力）。
  • 讨论中还提到了 Hypergrep/Hyperscan，它们在很多模式同时匹配时尤其快，但匹配语义比较棘手，并且存在构建/可移植性问题。

与 ripgrep/grep 相比的特性与差异

  • ugrep 可在基于 Debian 的仓库中获取，并且目标是与 GNU grep 兼容，包括选项和行为，不过用户也发现了一些具体的不兼容之处（例如 locale/字符类处理）。
  • 受到称赞的 ugrep 显著特性包括：
    • 内置分页器，并支持在结果中继续搜索（跨平台）。
    • 模糊匹配。
    • 尊重归档结构的递归归档搜索。
    • 交互式 TUI 和正则构建界面。
  • 也有人仍然更偏好 ripgrep，因为它工具链成熟、使用熟悉、速度“足够快”，而且默认行为强大。

正则语法与单词边界

  • 讨论集中在 POSIX BRE/ERE 与 PCRE 风格语法的争论上。
  • 一些用户坚持使用经典 grep 语法；另一些人则把它视为避开 grep 的理由。
  • ripgrep 的默认正则类似于 grep -E，并保证线性时间（不支持回溯引用/前后断言）。
  • 线程中还讨论了单词边界（\b、\<、\>）以及不同引擎对 Unicode“单词”定义的差异。

分页、TUI 与“用户友好”

  • ugrep 内置分页器对一些人来说是卖点，尤其是在 Windows 上；另一些人则把它看作反特性，更倾向于显式通过管道传给 less/其他分页器。
  • 线程中也提到了若干基于 ripgrep 的 TUI 和 fzf 集成作为替代方案。
  • “用户友好”在一些人看来指的是有交互式 TUI，而不是传统 CLI 的易用性。

索引与大型代码仓库

  • ugrep 的 n-gram 索引器确实存在，但据称速度较慢（例如，索引 Linux 内核树比 csearch 的 cindex 慢得多）。
  • 它会为每个目录创建索引文件，并被标记为 beta；重新索引是增量式的。

配置、标准与可移植性

  • ripgrep 使用基于环境变量的配置路径，而不是 XDG；一些人觉得这更简单，另一些人则不喜欢这种偏离。
  • 也有人质疑 XDG 在 Windows/macOS 上的适用性。
  • 一些用户不会采用非标准 grep，因为他们依赖于系统中始终存在的普通 grep，尤其是在受限制的环境或客户机器上。

其他工具与生态备注

  • 线程中还提到了 Hypergrep、grab、hound、csearch、ripgrep-all、fzf，以及各种分页器（less、bat 和其他）。
  • 该讨论强调，许多现代 grep 工具都“足够好”，选择往往取决于细微的特性/偏好，而不是某个工具的绝对优势。