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. On Wednesday, March 25, 2020 Harald van Dijk <a...@gigawatt.nl> 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 <a...@gigawatt.nl> 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 <oguzismailuy...@gmail.com > <mailto:oguzismailuy...@gmail.com>> wrote: > > > > echo n | sed '\n\nnd' > > > > Above command returns 'n' with GNU sed, and nothing with BSD seds and > > OmniOS sed. [...]
