Sorry, I was confusing the 'd' command, thinking 'display', for the 'l' command. Since stdout is supposed to echo after processing, I did have it reversed; if the gnu version echos the 'n' it probably wasn't 'delete'd, and for the others it likely was. On Wednesday, March 25, 2020 Harald van Dijk <[email protected]> wrote: On 25/03/2020 23:30, shwaresyst wrote: > yes, without them the argument would be "nnnd", after quote removal by > the shell. The reasoning in first reply was meant to show that the > non-GNU versions might be erroneously treating the second '\' as "do > contol alias processing always", ignoring that its use as delimeter > overrides that interpretation, to get the results observed.
Again, it's the BSD version that treats the second \n as <n>, treating the backslash in there as just escaping the delimiter character. You have it backwards. The GNU version is the one that treats the second \n as <newline>. > ------------------------------------------------------------------------ > On Wednesday, March 25, 2020 Harald van Dijk <[email protected]> wrote: > > On 25/03/2020 21:09, shwaresyst wrote: > > If it wasn't in single quotes, then that might be plausible, but I don't > > see it as the intent since no other aliases are excluded as > > possibilities for after the '/'. The initial "\n" makes 'n' the > > delimiter, the 2nd overrides it as being the BRE terminator, and the > > following 'n' is the terminator, before the 'd' command. Should there be > > something explicit about aliases not being usable when repurposed as > > delimiter, maybe. > > This reply makes no sense to me, sorry. The single quotes are processed > at the shell level. Without single quotes, there would be no backslash > for sed to process. > > Regardless, the only thing I wrote was that you simultaneously > considered the GNU version more correct and explained it in a way that > led me to believe you actually consider the BSD version more correct. I > wrote absolutely nothing about what the standard says or intends to say. > > > ------------------------------------------------------------------------ > > On Wednesday, March 25, 2020 Harald van Dijk <[email protected] > <mailto:[email protected]>> wrote: > > > > On 25/03/2020 19:44, shwaresyst wrote: > > > 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'. > > > > You have that backwards, don't you? The GNU version lets the use of \n > > as a control character take precedence over its use as a delimiter. > > That's why n gets printed: \n\nn is treated as /\n/, which can never > > match any single-line string, so nothing gets deleted. > > > > Likewise, > > > > echo n | sed '\n[^\n]nd' > > > > prints nothing with GNU sed, but prints n with FreeBSD sed for the same > > reason: 'n' does contain a character that is not <newline>, but does not > > contain any character that is not <n>. > > > > > > > > ------------------------------------------------------------------------ > > > On Wednesday, March 25, 2020 Oğuz <[email protected] > <mailto:[email protected]> > > <mailto:[email protected] > <mailto:[email protected]>>> wrote: > > > > > > > echo n | sed '\n\nnd' > > > > > > Above command returns 'n' with GNU sed, and nothing with BSD seds and > > > OmniOS sed. [...]
