bug#19842: sed bug: using -e instead of a literal newline in s replacement fails

[Evan Gates]

On Tue, Jan 24, 2017 at 8:05 PM, Assaf Gordon <address@hidden> wrote:
> Hello Evan and all,
>
> I'm triaging old sed bugs.
> (for past discussion, see https://bugs.gnu.org/19842 ).

Hi Assaf, thanks for taking the time to dig though this and respond.

> Second,
> Notice the backslash plays a role, indicating continuation for some
> implementations. Without backslash, '-e' are not always concatenated:
>
> Third,
> even in OpenBSD's sed which accepts this construct,
> it seems this is limited to 's'. It doesn't "just work"
> in all commands:

Yes the backslash is important and specific to the s command. In the
description of the s command POSIX says:

A line can be split by substituting a <newline> into it. The
application shall escape the <newline> in the replacement by preceding
it by a <backslash>.

So the examples without the backslash are irrelevant as are the
examples with the y command.

As for concatenation, POSIX says:

-e script
Add the editing commands specified by the script option-argument to
the end of the script of editing commands.

And more importantly:

If any -e or -f options are specified, the script of editing commands
shall initially be empty. The commands specified by each -e or -f
option shall be added to the script in the order specified. When each
addition is made, if the previous addition (if any) was from a -e
option, a <newline> shall be inserted before the new addition. The
resulting script shall have the same properties as the script operand,
described in the OPERANDS section.

This is a case where the previous addition was from a -e option, so a
newline should be inserted. After the newline is inserted the script
we have is

s/foo/bar\
baz/

And that "resulting script shall have the same properties..." means
that it should work the same as if it were in a file or in a single
argument with a literal newline.

> I'm marking this as 'done', but discussion can continue by replying to
> this thread. Better yet - if you have a patch that adds this
> functionality without causing regressions, we can look into
> incorporating it.

I do not have a patch, but if you are interested I can ask on the
Austin group list and see if there is any consensus and if so whether
they would change the wording of the standard.

Thank you for your time and work,
Evan