src/usr.bin/sed, branch upstream/13.1.0

sed(1): Add a reference for a 4.4BSD manual document

2021-04-15T12:43:10Z

Obtained from: OpenBSD (cherry picked from commit 9048d9a933f57991ee042618ab89dd49d8cbad89)

sed: fix hex_subst test after after r363679

2020-07-30T13:36:24Z

r363679 is in-fact the future change referenced by the comment, helpfully left and forgotten by kevans. Instead of just silently not matching, we should now be erroring out with vigor.

sed: treat '[' as ordinary character in 'y' command

2020-07-26T09:15:05Z

'y' does not handle bracket expressions, treat '[' as ordinary character and do not apply bracket expression checks (GNU sed agrees). PR: 247931 Reviewed by: pfg, kevans Tested by: antoine (exp-run), Quentin L'Hours Differential Revision: https://reviews.freebsd.org/D25640

sed/multi_test: print comment for current test, not next one

2020-07-13T01:32:37Z

This is visible when e.g. 8.20 is failing: not ok 96 8.20 # \ in y command 8.20's comment should be '[ as an s delimiter and its escapes'.

Remove some more duplicate test cases I accidentally committed

2020-06-11T18:14:34Z

Reported by: markj, yuripv MFC after: 2 weeks X-MFC-With: 362017

Remove duplicate lines from sed tests

2020-06-11T03:03:52Z

Reported by: yuripv Approved by: pfg (src) MFC after: 2 weeks X-MFC-With: 362017

Read commands from stdin when -f - is passed to sed(1)

2020-06-10T19:23:58Z

This patch teaches sed to interpret a "-" in a special way when given as an argument to the -f flag. This behavior is also present in GNU sed. PR: 244872 Tested by: antoine (exp-run) Reviewed by: pfg, tobik (older version) Approved by: pfg (src) Relnotes: yes MFC after: 2 weeks Differential Revision: https://reviews.freebsd.org/D24079

sed: attempt to learn about hex escapes (e.g. \x27)

2020-06-07T04:32:38Z

Somewhat predictably, software often wants to use \x27/\x24 among others so that they can decline worrying about ugly escaping, if said escaping is even possible. Right now, this software is using these and getting the wrong results, as we'll interpret those as x27 and x24 respectively. Some examples of this, when an exp-run was ran, were science/octopus and misc/vifm. Go ahead and process these at all times. We allow either one or two digits, and the tests account for both. If extra digits are specified, e.g. \x2727, then the third and fourth digits are interpreted literally as one might expect. PR: 229925 MFC after: 2 weeks

Update SYNOPSIS section to be consistent regarding -u, -i, and -I.

2020-05-19T09:17:20Z

Apparently, when the -u, -i and -I options where added to sed(1), it was forgotten to add them to both lines in the SYNOPSIS section. They were only added to the second line, although they apply to both. With the updated SYNOPSIS, it is now allowed (and consistent) to run: sed -i BAK s/foo/bar/g some_file PR: 240556 Submitted by: Oliver Fromme MFC after: 5 days

sed: process \r, \n, and \t

2019-12-10T19:16:00Z

This is both reasonable and a common GNUism that a lot of ported software expects. Universally process \r, \n, and \t into carriage return, newline, and tab respectively. Newline still doesn't function in contexts where it can't (e.g. BRE), but we process it anyways rather than passing UB \n (escaped ordinary) through to the underlying regex engine. Adding a --posix flag to disable these was considered, but sed.1 already declares this version of sed a super-set of POSIX specification and this behavior is the most likely expected when one attempts to use one of these escape sequences in pattern space. This differs from pre-r197362 behavior in that we now honor the three arguably most common escape sequences used with sed(1) and we do so outside of character classes, too. Other escape sequences, like \s and \S, will come later when GNU extensions are added to libregex; sed will likely link against libregex by default, since the GNU extensions tend to be fairly un-intrusive. PR: 229925 Reviewed by: bapt, emaste, pfg Differential Revision: https://reviews.freebsd.org/D22750