The GNU version is more correct, in my opinion, in that the use of n as a delimiter should take precedence over its use as control character alias with the wording as is. The other versions appear to consider the BRE as <newline> so does not match 'n'. On Wednesday, March 25, 2020 Oğuz <oguzismailuy...@gmail.com> wrote: echo n | sed '\n\nnd' Above command returns 'n' with GNU sed, and nothing with BSD seds and OmniOS sed. The standard says - In a context address, the construction "\cBREc", where c is any character other than <backslash> or <newline>, shall be identical to "/BRE/". If the character designated by c appears following a <backslash>, then it shall be considered to be that literal character, which shall not terminate the BRE. For example, in the context address "\xabc\xdefx", the second x stands for itself, so that the BRE is "abcxdef".
- The escape sequence '\n' shall match a <newline> embedded in the pattern space. A literal <newline> shall not be used in the BRE of a context address or in the substitute function. but this is not clear at all. Which is the correct behavior here? -- Oğuz
