diff options
Diffstat (limited to 'NEWS')
| -rw-r--r-- | NEWS | 115 |
1 files changed, 104 insertions, 11 deletions
@@ -1,4 +1,97 @@ -Sed 4.2.2 +GNU sed NEWS -*- outline -*- + +* Noteworthy changes in release 4.3 (2016-12-30) [stable] + +** Improvements + + sed's regular expression matching is now typically 10x faster + + sed now uses unlocked-io where available, resulting in faster I/O + operations. + +** Bug fixes + + sed no longer mishandles anchors ^/$ in multiline regex (s///mg) + with -z option (NUL terminated lines). [Bug introducted in sed-4.2.2 + with the initial implementation of -z] + + sed no longer accepts a ":" command without a label; before, it would + treat that as defining a label whose name is empty, and subsequent + label-free "t" and "b" commands would use that label. Now, sed emits + a diagnostic and fails for that invalid construct. + + sed no longer accesses uninitialized memory when processing certain + invalid multibyte sequences. Demonstrate with this: + echo a | LC_ALL=ja_JP.eucJP valgrind sed/sed 's/a/b\U\xb2c/' + The error appears to have been introduced with the sed-4.0a release. + + The 'y' (transliterate) operator once again works with a NUL byte + on the RHS. E.g., sed 'y/b/\x00/' now works like tr b '\0'. GNU sed + has never before recognized \x00 in this context. However, sed-3.02 + and prior did accept a literal NUL byte in the RHS, which was possible + only when reading a script from a file. For example, this: + echo abc|sed -f <(printf 'y/b/\x00/\n')|cat -A + is what stopped working. [bug introduced some time after sed-3.02 and + prior to the first sed-4* test release] + + When the closed-above line number ranges of N editing commands + overlap (N>1), sed would apply commands 2..N to the line just + beyond the largest range endpoint. + [bug introduced some time after sed-4.09 and prior to release in sed-4.1] + Before, this command would mistakenly modify line 5: + $ seq 6|sed '2,4d;2,3s/^/x/;3,4s/^/y/' + 1 + yx5 + 6 + Now, it does not: + $ seq 6|sed '2,4d;2,3s/^/x/;3,4s/^/y/' + 1 + 5 + 6 + + An erroneous sed invocation like "echo > F; sed -i s//b/ F" no longer + leaves behind a temporary file. Before, that command would create a file + alongside F with a name matching /^sed......$/ and fail to remove it. + + sed --follow-symlinks now works again for stdin. + [bug introduced in sed-4.2.2] + + sed no longer elides invalid bytes in a substitution RHS. + Now, sed copies such bytes into the output, just as Perl does. + [bug introduced in sed-4.1 -- it was also present prior to 4.0.6] + + sed no longer prints extraneous character when a backslash follows \c. + '\c\\' generates control character ^\ (ASCII 0x1C). + Other characters after the second backslash are rejected (e.g. '\c\d'). + [bug introduced in the sed-4.0.* releases] + + sed no longer mishandles incomplete multibyte sequences in s,y commands + and valid multibyte SHIFT-JIS characters in character classes. + Previously, the following commands would fail: + LC_ALL=en_US.UTF-8 sed $'s/\316/X/' + LC_ALL=ja_JP.shiftjis sed $'/[\203]/]/p' + [bug introduced some time after sed-4.1.5 and before sed-4.2.1] + +** 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. + +** Build-related + + "make dist" now builds .tar.xz files, rather than .tar.gz ones. + xz is portable enough and in wide-enough use that distributing + only .tar.xz files is enough. It has been fine for coreutils, grep, + diffutils and parted for a few years. + + +** New Features + + new --sandbox option rejects programs with r/w/e commands. + + +* Noteworthy changes in release 4.2.2 (2012-12-22) [stable] * don't misbehave (truncate input) for lines of length 2^31 and longer @@ -120,7 +213,7 @@ Sed 4.1.1 * yield an error when running -i on terminals or other non regular files -* do not interpret - as stdin when running in in-place editing mode +* do not interpret - as stdin when using in-place editing mode * fix bug that prevented 's' command modifiers from working @@ -426,15 +519,15 @@ NUL character. Had the glibc folk fix a bug in lib/regex.c where * The s/// command now understands the following escapes (in both halves): - \a an "alert" (BEL) - \f a form-feed - \n a newline - \r a carriage-return - \t a horizontal tab - \v a vertical tab - \oNNN a character with the octal value NNN - \dNNN a character with the decimal value NNN - \xNN a character with the hexadecimal value NN + \a an "alert" (BEL) + \f a form-feed + \n a newline + \r a carriage-return + \t a horizontal tab + \v a vertical tab + \oNNN a character with the octal value NNN + \dNNN a character with the decimal value NNN + \xNN a character with the hexadecimal value NN This behavior is disabled if POSIXLY_CORRECT is set, at least for the time being (until I can be convinced that this behavior does not violate the POSIX standard). (Incidentally, \b (backspace) was omitted because |