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

Question

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

当我使用 grep 命令时

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

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

3:3206721:CAATCGCCGT
3:4140348:CAATCGCCGT

我和凯特一起在原始文件上搜索了底漆，但没有找到。由于文本分为 70 列，引物可能会分成两行。

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

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

然而，底漆不在那里。

grep 可以处理的最大行数有限制吗？如果是这样，当超过限制时，结果在限制大小内是否可靠？

---

• 我的示例文件可以在github上访问
• An，还有单行文件。

Answer 1

一般来说

POSIX规范grep指出

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

它意味着grep必须可靠地处理文本文件（“应”意味着“强制行为”）。非文本文件的文件可能会或可能不会被可靠地处理，未指定行为。

这里的“文本文件”意味着[强调我的]：

包含组织成零行或多行的字符的文件。这些行不包含 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。Ubuntu 附带 GNU grep。GNUgrep 声称：

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