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

[Norihiro Tanaka]

On Tue, 17 Feb 2015 16:23:54 -0800
Evan Gates <address@hidden> wrote:

> Hi Norihiro,
> 
> Thanks for replying. I respectfully disagree with your interpretation.
> 
> The -e and -f options talk about "the script of editing commands" as
> the entire script/program that will run once sed starts reading input.
> Both -e and -f add commands to "the end of the script of editing
> commands." The line you quoted uses the exact same phrase:
> 
> 1) -e  script
> Add the editing commands specified by the script option-argument to
> the end of the script of editing commands.
> 2) -f  script_file
> Add the editing commands in the file script_file to the end of the
> script of editing commands.
> 3) If any -e or -f options are specified, the script of editing
> commands shall initially be empty.
> 
> I posit that "the script of editing commands" means the same thing in
> all three places. Therefore (3) means that the script/program that sed
> will run is empty before the first -e or -f.
> 
> Your interpretation would cause "the script of editing commands" to
> mean something different in (3) than it means in (1) and (2).
> 
> Thank you,
> Evan

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