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

[Norihiro Tanaka]

On Wed, 11 Feb 2015 17:20:24 -0800
Evan Gates <address@hidden> wrote:

> Hello,
> 
> sed 's/foo/bar\
> baz/'
> 
> works as expected. But using multiple -e instead of a literal newline fails:
> 
> $ sed -e 's/foo/bar\' -e baz/
> sed: -e expression #1, char 10: unterminated `s' command
> 
> The following is from POSIX[0]:
> 
> 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.
> 
> My reading of that leads me to believe that the two commands should
> create identical scripts, but GNU sed seems to me interpreting the
> script before the addition of the newline and second -e's argument.
> 
> Is this a bug or desired behavior?
> 
> Thanks,
> Evan
> 
> $ sed --version
> sed (GNU sed) 4.2.2
> Copyright (C) 2012 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>.
> This is free software: you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law.
> 
> Written by Jay Fenlason, Tom Lord, Ken Pizzini,
> and Paolo Bonzini.
> GNU sed home page: <http://www.gnu.org/software/sed/>.
> General help using GNU software: <http://www.gnu.org/gethelp/>.
> E-mail bug reports to: <address@hidden>.
> Be sure to include the word ``sed'' somewhere in the ``Subject:'' field.
> 
> [0] 
> http://pubs.opengroup.org/onlinepubs/9699919799/utilities/sed.html#tag_20_116_04

Hi,

I interprete following as multiple `-e' option does not merge fragments
of two commands.

  # If any -e or -f options are specified, the script of editing commands
  # shall initially be empty.

i.e. the command by first -e option is parsed without the completion,
the buffer is initialized into empty before next -e option.

Thanks,
Norihiro