sed 命令在每个操作系统之间的行为差异及其含义
我在 sed 命令的工作行为之间发现了一个奇怪但有效的差异。坦白说，这让我感到非常惊讶。
现在让我们看一下SUSE Linux 和HP (IA64) 的sed 的手册页。
SUSE Linux：
描述 Sed 是一个流编辑器。流编辑器用于执行基本文本 输入流（文件或来自管道的输入）上的转换。 虽然在某些方面类似于允许脚本编辑的编辑器 （例如 ed），sed 的工作原理是仅对输入进行一次传递，并且 因此效率更高。但这是 sed 过滤文本的能力 在管道中，它与其他类型的管道有特别的区别 编辑们。
HP IA64：
描述 sed 将指定的文本文件（默认标准输入）复制到标准输出，并根据最多包含 100 个命令的脚本进行编辑。仅处理完整的输入行。 文件末尾任何不以换行符结尾的输入文本都将被忽略
突出显示的文本似乎是工作行为的主要区别。因此，在移植过程中，我的所有脚本在 HP-UX IA64 计算机中开始失败。
问题：
一个。难道没有什么底层标准强制每个供应商在实现上必须基本一致吗？
b.如果有一些命令可以确认，而另一些命令则不能确认，任何人都可以发布符合标准的列表。
c.现在我有很多这样的命令用作我的项目脚本的一部分。除了测试所有场景的每个命令之外，检查/避免此类错误的最佳方法是什么？
基本上在这种情况下，我将面临确认软件适用于跨供应商平台的所有场景的问题。
I have come across a strange but valid difference between the working behavior of sed command. To be frank this has come as a very big surprise to me.
Now let us look at the man pages of sed of SUSE Linux and HP (IA64).
SUSE Linux:
DESCRIPTION
Sed is a stream editor. A stream editor is used to perform basic text
transformations on an input stream (a file or input from a pipeline).
While in some ways similar to an editor which permits scripted edits
(such as ed), sed works by making only one pass over the input(s), and
is consequently more efficient. But it is sed's ability to filter text
in a pipeline which particularly distinguishes it from other types of
editors.
HP IA64 :
DESCRIPTION
sed copies the named text files (standard input default) to the standard output, edited according to a script containing up to 100 commands. Only complete input lines are processed. Any input text at the end of a file that is not terminated by a new-line character is ignored
The highlighted text, seems to be a major difference in working behavior. So all my scripts started failing in the HP-UX IA64 machine during porting.
Question :
a. Isn't there any underlying standard that force each vendor to have basic conformity with the implementation?
b. In case there are some commands which confirm and others which cannot confirm, can anyone post the list that adhere to standards.
c. Now I have a lot of such command that are used as part of my project scripting. What is the best way to check/avoid such kind of error - apart from testing each and every command for all scenario?
Basically In such scenario I would be facing problem confirming software working for all scenarios across vendor platforms.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
从 POSIX 的角度来看，HP-UX 忽略最后一个换行符之后的文本的行为没有任何问题。关键在于应用程序要求
sed的输入文件是文本文件。这意味着不能有任何 NUL 字节，行长度限制为 {LINE_MAX} （包括换行符），并且如果文件不为空，则文件必须以换行符结尾（因为行必须以换行符结尾）。如果应用程序使用非文本文件的输入文件调用 sed，则行为未定义。这种情况的其他常见行为包括使用不以换行符结尾的“行”运行脚本 (GNU sed)，并在缺少换行符时添加最后一个换行符 (FreeBSD sed)。
100 个命令的限制似乎更值得怀疑；我没有看到一个句子允许这样的限制。
POSIX.1-2008 参考文献：XBD 3.205 行、XBD 3.394 文本文件、XCU 4 实用程序 sed。
From a POSIX perspective, nothing is wrong with the HP-UX behaviour of ignoring text after the last newline. The key is in the requirement on the application that
sed's input files be text files. This means that there may not be any NUL bytes, line length is limited to {LINE_MAX} (including the newline) and the file must end with a newline if it is not empty (because a line must end in a newline). If the application callssedwith an input file that is not a text file, the behaviour is undefined.Other common behaviours for this situation include running the script with a "line" that does not end in a newline (GNU sed) and adding a final newline if one is missing (FreeBSD sed).
The limit of 100 commands seems more questionable; I do not see a sentence that allows such a limit.
POSIX.1-2008 references: XBD 3.205 Line, XBD 3.394 Text File, XCU 4 Utilities sed.