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 <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
<mailto: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>
> <mailto: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. [...]
