[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#19842: sed bug: using -e instead of a literal newline in s replaceme
bug#19842: sed bug: using -e instead of a literal newline in s replacement fails
Wed, 18 Feb 2015 22:24:46 +0900
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,
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/