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 <> 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?


Reply via email to