sed 命令在每个操作系统之间的行为差异及其含义答案

【问题标题】：sed command difference in behaviour between each OS and its implicationsed 命令在每个操作系统之间的行为差异及其含义
【发布时间】：2015-02-19 07:06:30
【问题描述】：

我发现sed 命令的工作行为之间存在一个奇怪但有效的区别。坦率地说，这对我来说是一个非常大的惊喜。

现在让我们看一下 SUSE Linux 和 HP (IA64) 的 sed 的手册页。

SUSE Linux：

描述 Sed 是一个流编辑器。流编辑器用于执行基本文本输入流（来自管道的文件或输入）的转换。虽然在某些方面类似于允许脚本编辑的编辑器（例如 ed），sed 通过只对输入进行一次传递来工作，并且因此效率更高。但它是 sed 过滤文本的能力在一个特别区别于其他类型的管道中编辑。

HP IA64：

描述 sed 将命名的文本文件（标准输入默认）复制到标准输出，根据包含多达 100 个命令的脚本进行编辑。仅处理完整的输入行。 文件末尾未由换行符终止的任何输入文本都将被忽略

突出显示的文本似乎是工作行为的主要区别。所以我所有的脚本在移植过程中都开始在 HP-UX IA64 机器上失败。

问题：
一个。是否有任何底层标准强制每个供应商与实现基本一致？

b.如果有一些命令可以确认而另一些不能确认，任何人都可以发布符合标准的列表。

c。现在我有很多这样的命令被用作我的项目脚本的一部分。检查/避免此类错误的最佳方法是什么 - 除了为所有场景测试每个命令之外？

基本上在这种情况下，我将面临确认软件适用于所有场景跨供应商平台的问题。

【问题讨论】：

脚本中 100 条命令的限制似乎也很随意！我主要在 Solaris 环境（和一些 AIX）中工作，与 Linux 的 GNU 工具相比，这些环境是有限的，但是当我过去阅读新闻组时，HP unix 似乎总是有更多的机会 i> 用于重新编码。你知道 Unix 工具的 POSIX 定义吗？并不意味着惠普必须跟随他们。添加一个 Posix 标签，也许真正的 Posix 大师会为您提供一些真正的答案。祝你好运。
底层标准规定文本文件中的行应以换行符结尾；任何不符合会导致未定义行为的事情。不要在不以换行符结尾的文件上使用sed；它不是便携式的 - 因为你刚刚发现了困难的方式！
sed 的不同版本之间的差异很大。这是难以编写可移植 shell 脚本的原因之一。一个实用的解决方法可能是将您的 sed 脚本转换为 Perl； Perl 发行版带有一个实用程序s2p，它会自动执行此操作。当然，Perl 甚至没有正式指定，但由于只有一个实现，它是可移植的。（您可能仍然会遇到不同版本行为不同的极端情况，但可能不会出现在s2p 生成的脚本中。）

标签： shell unix command-line posix

【解决方案1】：

从 POSIX 的角度来看，HP-UX 忽略最后一个换行符之后的文本的行为并没有错。关键在于应用程序要求sed 的输入文件是文本文件。这意味着可能没有任何 NUL 字节，行长度限制为 {LINE_MAX}（包括换行符），如果文件不为空，则文件必须以换行符结尾（因为行必须以换行符结尾）。如果应用程序使用非文本文件的输入文件调用sed，则行为未定义。

这种情况下的其他常见行为包括使用不以换行符结尾的“行”运行脚本 (GNU sed)，并在缺少换行符时添加最后一个换行符 (FreeBSD sed)。

100 个命令的限制似乎更值得怀疑；我没有看到允许这样限制的句子。

POSIX.1-2008 参考：XBD 3.205 Line、XBD 3.394 Text File、XCU 4 Utilities sed。

【讨论】：

您的回答非常有用。您能否发布一个链接，在其中提到这些作为 POSIX 的一部分（谷歌是否 - 找不到答案）。我想验证标准并为项目准备一份清单。
pubs.opengroup.org/onlinepubs/007904875/utilities/sed.html 是 Google 搜索“posix sed”的热门搜索结果。