Description of problem:
RHEL7's /bin/sed (sed-4.2.2) is 5.5 years old, with no significant package update, in spite of the many improvements and bug fixes since then. Notable improvements from 4.3:
- sed's regular expression matching is now typically 10x faster
- sed now uses unlocked-io where available, resulting in faster I/O operations.
Recently, I released sed-4.5 , with fixes for a few more bugs.
Would you please consider including newer sed in CentOS 7?
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. /bin/sed --version|head -1
/bin/sed (GNU sed) 4.2.2
sed 4.5 or newer
we try to avoid major package upgrades within a single major version of RHEL (mainly to minimize possible incompatibilities with existing scripts), so unless there is some business justification or other important reason, I do not plan to update sed within the RHEL-7 (on the other hand, I've already updated sed to 4.5 in Fedora rawhide).
I completely understand the general aversion to upgrading anything for RHEL.
However, the only incompatibility is this, from 4.3:
** Feature removal
The "L" command (format a paragraph like the fmt(1) command would)
has been listed in the documentation as a failed experiment for at
least 10 years. That command is now removed.
Did you even know about the "L" command? I didn't :-)
Really stretching the term "incompatibility", one might also include
this from 4.5, though I call this a clear bug fix:
sed now treats the sequence '\x5c' (ASCII 92, backslash) as literal
backslash character, not as an escape prefix character.
[Bug present since sed-3.02.80]
$ echo z | sed -E 's/(z)/\x5c1/' # identical to 's/(z)/\1/'
$ echo z | sed -E 's/(z)/\x5c1/'
If the "L" removal is your only objection, I would be willing to reintroduce it and even consider making a new release just for that.
I agree with Jakub here. Each single bug fix (not only the mentioned one) can potentially break existing scripts that rely on the buggy behavior. Therefore, we do not rebase packages in already released products unless we have a business justification for the rebase. That is the added value of RHEL.
Even though many of the changes made during the last five years are clear bug fixes, as Kamil mentioned, we can't be really sure that there are no scripts that depend on the buggy behavior. Out of the top of my head, I would add the bug with handling symlinks and selinux context to the list of incompatibilities you mentioned and I suppose that others could be found. And since the sed is one of the critical components of the system, I really do not want to introduce any (possible) incompatibilities within released RHEL, unless I really have to.
Another potential issue: we introduced the DFA matcher. That's what gains the 10x speed-up. But unless the boundary between it and the other matchers is perfect, there could be subtle differences there, too.