Bug 1564789 - sed-4.2.2 is 5.5 years old: sed-4.5 has notable improvements
Summary: sed-4.2.2 is 5.5 years old: sed-4.5 has notable improvements
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: sed
Version: 7.7
Hardware: All
OS: Linux
unspecified
medium
Target Milestone: rc
: ---
Assignee: Jakub Martisko
QA Contact: qe-baseos-tools
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2018-04-07 21:49 UTC by Jim Meyering
Modified: 2018-04-10 14:42 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2018-04-09 08:04:08 UTC


Attachments (Terms of Use)

Description Jim Meyering 2018-04-07 21:49:54 UTC
Description of problem:

Hello,

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[1] 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 [2], with fixes for a few more bugs.

Would you please consider including newer sed in CentOS 7?
Thanks,
Jim

[1] https://git.savannah.gnu.org/cgit/sed.git/tree/NEWS
[2] https://lists.gnu.org/r/sed-devel/2018-03/msg00021.html


Version-Release number of selected component (if applicable):
sed-4.2.2-5

How reproducible:
always

Steps to Reproduce:
1. /bin/sed --version|head -1

Actual results:
/bin/sed (GNU sed) 4.2.2

Expected results:
sed 4.5 or newer

Additional info:

Comment 2 Jakub Martisko 2018-04-09 08:04:08 UTC
Hello Jim,

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). 

Regards,
Jakub

Comment 3 Jim Meyering 2018-04-09 21:25:27 UTC
Hi Jakub,

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]
  Old behavior:
     $ echo z | sed -E 's/(z)/\x5c1/' # identical to 's/(z)/\1/'
     z
  New behavior:
     $ echo z | sed -E 's/(z)/\x5c1/'
     \1

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.

Comment 4 Kamil Dudka 2018-04-09 21:43:25 UTC
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.

Comment 5 Jakub Martisko 2018-04-10 08:31:20 UTC
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.

Comment 6 Jim Meyering 2018-04-10 14:42:03 UTC
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.


Note You need to log in before you can comment on or make changes to this bug.