I'm starting with the easy cases. The leftovers need to be looked at a
bit more closely.
Note that this change _does_ modify the code of the old tests. This is
required in order to allow the code to locate the data files in the
source directory instead of the current directory, because Kyua
automatically changes the latter to a temporary directory.
Also note that at least one test is known to be broken here. Actually,
the test is not really broken: it's marked as a TODO but unfortunately
Kyua's TAP parser currently does not understand that. Will have to be
fixed separately.
In BSD, fgetln() available in libc but in Illumos the Solaris port had to
include it internally. It also seems to have caused problems [1].
Aid portability by using getline() instead.
Reference:
https://www.illumos.org/issues/3820 [1]
Submitted by: Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.com>
Reviewed by: dds
MFC after: 2 weeks
When creating a backup file, sed renamed the original before renaming the
changed copy into place, leading to a short time when no file with the
original name was present (usually only visible on SMP systems). Try
creating the backup file using a hard link instead, avoiding this problem.
If creating the hard link fails for any reason, fall back to the old rename
method.
When not creating a backup file, sed already renamed the changed copy onto
the original. This remains unchanged.
I am not adding the suppression of redundant fchown/fchmod to this commit,
because FreeBSD appears to check this in the kernel (for msdosfs at least).
PR: bin/153261
Submitted by: Pedro F. Giffuni
Reviewed by: dds (older version)
Obtained from: Illumos
MFC after: 2 weeks
"The escape sequence '\n' shall match a <newline> embedded in
the pattern space."
It is unclear whether this also applies to a \n embedded in a
character class. Disable the existing handling of \n in a character
class following Mac OS X, GNU sed version 4.1.5 with --posix, and
SunOS 5.10 /usr/bin/sed.
Pointed by: Marius Strobl
Obtained from: Mac OS X
of the y (translate) command.
"If a backslash character is immediately followed by a backslash
character in string1 or string2, the two backslash characters shall
be counted as a single literal backslash character"
Pointed by: Marius Strobl
Obtained from: Mac OS X
specification and regression test regress:25.
"A function can be preceded by one or more '!' characters, in which
case the function shall be applied if the addresses do not select
the pattern space."
MFC after: 2 weeks
parenthesized subexpression is defined. For example, the
following command line caused unexpected behavior like
segmentation fault:
% echo test | sed -e 's/test/\1/'
PR: bin/126682
MFC after: 1 week
backslash if he/she wants to use a non-traditional delimiter, i.e.,
anything other than a slash. That is, /abc/ works as is, but xabcx
needs to be spelled as \xabcx.
Add appropriate markup.
Bump Dd.
Checked with: IEEE Std 1003.1, 2004 Edition
MFC after: 3 days
1) Add missing parens around assignment that is compared to zero.
2) Make some variables that only take non-negative values unsigned.
3) Some casts/type changes to fix other constness warnings.
4) Make one variable a const char *.
5) Make sure termwidth is positive, it doesn't make sense for it to be negative.
Approved by: dds
whether we should ignore case, determine the flag by calling
compile_flags() first. Also, make sure that we obtain an
initialized cmd->u.s buffer before processing further. We
may want to refine this solution later, but for now, make
the changes in order to unbreak world build after a sed(1)
with rev. 1.29 of compile.c is installed.
Approved by: re (hrs)
each file independently from other files. The new semantics are
desired in the most of practical cases, e.g.: delete lines 5-9
from each file.
Keep the previous semantics of -i under a new option, -I, which
uses a single continuous address space covering all files to edit
in-place -- they are too cool to just drop them.
Add regression tests for -i and -I.
Approved by: dds
Compared with: GNU sed
Discussed on: -hackers
MFC after: 2 weeks
and had no chance to match it by the 2nd address precisely.
Otherwise the unclosed range would bogusly extend to the end
of stream.
Add a basic regression test for the bug fixed. (This change
also fixes the more complex case 5.3 from `multitest.t'.)
Compared with: SUN and GNU seds
Tested by: regression tests
MFC after: 1 week
in parentheses. The ?: operator has a remarkably low precedence, so
expressions like (MATCH(foo) && bar) would have an unexpected meaning
w/o the parentheses around MATCH().
Tested with: md5(1)
them are related to the `c' function's need to know if we are at
the actual end of the address range. (It must print the text not
earlier than the whole pattern space was deleted.) It appears the
only sed function with this requirement.
There is `lastaddr' set by applies(), which is to notify the `c'
function, but it can't always help because it's false when we are
hitting the end of file early. There is also a bug in applies()
due to which `lastaddr' isn't set to true on degenerate ranges such
as `$,$' or `N,$' if N appears the last line number.
Handling early EOF condition in applies() could look more logical,
but it would effectively revert sed to the unreasonable behaviour
rev. 1.26 of main.c fought against, as it would require lastline()
be called for each line within each address range. So it's better
to call lastline() only if needed by the `c' function.
Together with this change to sed go regression tests for the bugs
fixed (c1-c3). A basic test of `c' (c0) is also added as it helped
me to spot my own error.
Discussed with: dds
Tested by: the regression tests
MFC after: 1 week
used once on a non-empty pattern space and then again on an empty
pattern space, the second usage restores the pattern space length to
the length that it had when the first "P" was used.
PR: bin/96052
Submitted by: Andrey Zholos <aaz@althenia.net>
MFC after: 7 days
When sed is asked to inline-edit files, it forgets to close the temporary
file and runs out of descriptors for long command lines (assuming you reset
kern.maxfilesperproc to something sane that's less than the number of files
passed to sed).
subtract one unsigned number from another potentially smaller
one, leading to wraparound (and heap corruption, eventually).
PR: 58813
MFC after: 2 weeks
regular expression as the first argument to a substitute command. If
used to test a sed which (erroneously) evaluates this at translation
time rather than at execution time, the bugged sed is put into an
infinite loop. This mode of failure seems excessive. Such a failing
sed is the Free Software Foundation's sed 3.02.
The specific test was also not being executed for the BSD sed.
Both problems are now fixed.
PR: misc/25585
Submitted by: Walter Briscoe <w.briscoe@ponl.com>
Approved by: schweikh (mentor)
MFC after: 2 weeks
whose true and false clauses were equivalent with a check that we are
not about to stumble off the end of the line.
Reported by: peter
Pointy hat to: fanf
There are two bugs: in the s///g case, the substitution didn't occur
at the end of the line; in the s///N case, the code didn't count
forwards along the line properly. See the sg, s3, s4, and s5 tests
in src/tools/regression/usr.bin/sed/.
Reviewed by: tjr
need to know. Instead, check when we are trying to match a "$" address.
This does not change the way sed processes regular files, but makes it behave
more sensibly when used interactively.
PR: 40101
MFC after: 2 weeks
instead add the newline when the pattern space is printed. Make the `G' and
`H' commands add a newline to the space before the data, remove bogus
addition of newline from `x' command.
PR: 29790, 38195
- original version of code worked incorrectly when more than one
input files were specified - it was moving the last line from the 1st file
to be the first line of the 2nd, last line of the 2nd to be the first
line of the 3rd and so on;
- use mmap()->write() to create temporary file instead of
malloc()->read()->write(), which was not only slower, but also did not
bother to free allocated memory once backup file was created, potentially
leading to memory exhausting when regex is applied to a big file or a large
number of small ones.
