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

[Evan Gates]

On Wed, Feb 18, 2015 at 5:24 AM, Norihiro Tanaka <address@hidden> wrote:
> Hi Evan,
>
> Sorry, I was wrong.  However, it is not written in anywhere that multiple
> -e and/or -f options must be analyzed after the concatenation.  It may be
> concatenated after each -e and/or -f options are parsed.
>
> By the way, /usr/bin/sed and /usr/xpg4/bin/sed on Solaris 11, /usr/bin/sed
> on HP-UX 11.23 also behave as same as GNU sed.  In other words, they also
> return an error code for following.
>
>   $ sed -e 's/foo/bar\' -e baz/
>
> Thanks,
> Noririro
>

Hi Norihiro,

The POSIX description of sed doesn't make any assumptions about the
inner workings of sed. It says nothing about analyzing, compiling,
building the internal structures, it only talks about adding to "the
script of editing commands" which will then be run. "The script of
editing commands" refers to a representation of the editing commands
in accord with the  descriptions that follow on the page, i.e. text
commands, a sed script. This is supported by the following line:

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 newline is mentioned because it is referring to the text
representation of the script (the only representation mentioned on the
page). It explains that all the parts from -e and -f should in effect
be concatenated to a single sed script, with newlines after the -e
option arguments. e.g.:

sed -e 's/foo/bar\' -e 'baz/'

and

printf %s\\n 's/foo/bar\' 'baz/' > script
sed -f script

should be identical, due to that newline.

Thanks,
Evan