CODEWITHSUNDEEP
shellunixcommand-lineposix
kumar_m_kiran
kumar_m_kiran

Reputation: 4022

sed command difference in behaviour between each OS and its implication

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.

Upvotes: 2

Views: 1031

Answers (1)

jilles
jilles

Reputation: 11232

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 calls sed with 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.

Upvotes: 3

Related Questions