☰

grep 命令正确处理的行长度是否有限制？

tag-icon • tag-icon ubuntu grep
grep 命令正确处理的行长度是否有限制？

当我检查结果时我的 biostar 实现在 fasta 文件中搜索素数时，我看到了一个奇怪的结果。我原本有一个 70 列的文件，并将其转换为一行中有 6077828 个字符的文件。

当我使用 grep 命令时

grep -o -P -b -n CAATCGCCGT fasta.txt

它显示了两个在我的 Biostar 实现中未显示的匹配。

3:3206721:CAATCGCCGT
3:4140348:CAATCGCCGT

我和 Kate 一起在原始文件上搜索了引文，但没找到。由于文本分为 70 列，所以引文可能分为两行。

然后我用 div 和 mod 将它们转换为行号和列号

  • 3206572 代表第 45808 行第 12 列
  • 4140199 代表第 59145 行第 49 列

但底漆却不在那里。

grep 可以处理的最大行数是否有限制？如果有，当超过限制时，结果是否可靠，直至达到限制大小？

  • 我的示例文件可以在github
  • 一个单行文件那里， 也。

答案1

一般来说

这POSIX 规范grep指出

输入文件
输入文件应为文本文件。

这意味着grep必须可靠地处理文本文件（“shall” 表示“必须的行为”)。非文本文件可能被可靠地处理，也可能不被可靠地处理，其行为尚未指定。

此处为“文本文件”方法[强调我的]：

包含字符的文件，这些字符被组织成零行或多行。这些行不包含 NUL 字符，并且{LINE_MAX}长度不能超过字节，包括 <newline> 字符。尽管 POSIX.1-2017 不区分文本文件和二进制文件（请参阅 ISO C 标准），许多实用程序在操作文本文件时仅产生可预测或有意义的输出。具有此类限制的标准实用程序始终在其 STDIN 或 INPUT FILES 部分中指定“文本文件”。

{LINE_MAX}被解释这里：

{LINE_MAX}
除非另有说明，当实用程序被描述为处理文本文件时，实用程序输入行（标准输入或其他文件）的最大长度（以字节为单位）。长度包括尾随 <newline> 的空间。
最小可接受值：{_POSIX2_LINE_MAX}

{_POSIX2_LINE_MAX}
除非另有说明，当实用程序被描述为处理文本文件时，实用程序输入行（标准输入或其他文件）的最大长度（以字节为单位）。长度包括尾随 <newline> 的空间。
值：2048

所有这些意味着的实现可能会错误处理比给定系统grep更长的行，但仍然可以称其为“可移植”。可能低至 2048。{LINE_MAX}{LINE_MAX}

请记住，并不是有人想出了规范，而不同实现的维护者却grep努力去遵循。事实恰恰相反：现有的主要实现已经过检查，共同的功能集已找到并记录下来。可能需要稍微赶上一些。有些可能功能强大得多；有些可能从一开始就被认为是非主要的，由于某种原因能力较弱，有理由不赶上。

不管怎样，你可以grep期待面向 POSIX 的操作系统（例如 Linux），尤其是使用 POSIX 认证的操作系统（例如 macOS）来可靠地处理长度不超过 2048 字节且不包含 NUL 字符的行。如果grep可以处理更长的行，那么就将其视为奖励。

“一行的长度有限制吗？”的一般答案是：是的，可能有，这取决于实现；但如果有限制，则至少应为 2048 字节。较长的行的行为尚未指定。

尤其

您已标记. Ubuntu 附带 GNU grep. GNUgrep 声称这：

虽然grep期望对文本进行匹配，但除了可用内存外，它对输入行的长度没有限制，并且它可以匹配一行中的任意字符。

相关内容