FreeBSD 11.0 new sed behaviour


Al of a sudden sed began to act differently on FreeBSD 11
On FreeBSD 11.0 following script (<------> - tab character)
# cat file

#cat testscript.sed
sed -E -i '.orig' \
<------>-e '/^SEARCHED_LINE/ a\
<------>\<------>line3' \

performs this output:


While on FreeBSD 10.3 and previuos versions it performed this:


Does somebody know why FreeBSD devs have changed pretty sane and convenient sed's behaviour to gsed's one?
My scripts looked very neat and structured with previous BSD sed.
Do I have to rewrite all my scripts now?
  • Thanks
Reactions: Oko
Check if they did't replace sed with gsed. Check if there is OpenBSD sed in ports and use that one.
sed has only one hardlink, haven't found gsed in base:

$ type sed
sed is a tracked alias for /usr/bin/sed
$ ll /usr/bin/sed
-r-xr-xr-x  1 root  wheel  37784 25 сент. 16:04 /usr/bin/sed
$ gsed
mksh: gsed: not found

And no any new key in sed which would switch it's behaviour from GNU to BSD.

Haven't found OpenBSD's sed in ports, while I've found gsed in ports - textproc/gsed.
Then why replicate gsed behaviour in BSD sed?
How will this help? OpenBSD 6.0's sed behaves the same way.
In the past a few userland tools in FreeBSD got replaced with GNU versions then they were revert back to BSD versions. I was sleepy when I answered the original post but not so sleepy not to know that OpenBSD version of sed is true BSD version (I even know the guy who maintaining it). Thus I posted quick answer. I will make sure I keep my tongue in check :)
Your example is a little bit complicated there was another thread of a similar sort recently:

Thread 57539

In a nutshell, the new behaviour of sed(1) is not to output a newline when the input hasn't any. Is your example related to this change as well?
No, it doesn't relate to Thread 57539

There's nothing complicated actually, I just wanted to highlight that classic BSD behaviour for a/c/i operands has been changed silently in 11.0 and it's very uncomfortable for some people.