to wcscoll(3). Newline characters could cause incorrect results when
comparing lines.
Also, if an input line didn't contain a newline character, it was
omitted from the output. According to my interpretation, SUSv3 requires
that the newline is always printed.
Add regression tests for the cases. [1]
PR: bin/140976
Submitted by: D'Arcy Cain (original version) [1]
Approved by: trasz (mentor)
"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
colliding upper case letters as the lower case letter with a '_' in
front.
MFC after: 3 days
Discussed with: ed
Spotted by: Michael David Crawford <mdc at prgmr.com>
The jot(1) regression tests directory contained two tests named `wx' and
`wX', which doesn't work on case insensitive filesystems. Rename `wX' to
`wX1'.
MFC after: 1 month
"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."
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 a more reasonable way than BSD sed does: they properly
close the range even if we branched over its end. No doubt,
the range `1,5' should not match lines from 9 through 14.
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
I have verified these with GNU sed 4.1.5 (and in some cases with Solaris
sed) and they are identical, with the following exceptions:
5.3: The result is unspecified and BSD sed behaves differently.
6.3: GNU sed gets it wrong
7.1: GNU sed gets it wrong
7.8: BSD sed gets it wrong
According to IEEE Std 1003.1, 2004 "Whenever the pattern space is
written to standard output or a named file, sed shall immediately
follow it with a <newline>."
An attempt at the same correction might have been made with r1.3,
which is however identical with r1.2.
wildcard specifications. Earlier the only wildcard syntax
was "-j 0" for "any jail". There were at least
two shortcomings in it: First, jail ID 0 was abused; it
meant "no jail" in other utils, e.g., ps(1). Second, it
was impossible to match processed not in jail, which could
be useful to rc.d developers. Therefore a new syntax is
introduced: "-j any" means any jail while "-j none" means
out of jail. The old syntax is preserved for compatibility,
but now it's deprecated because it's limited and confusing.
Update the respective regression tests. While I'm here,
make the tests more complex but sensitive: Start several
processes, some in jail and some out of jail, so we can
detect that only the right processes are killed by pkill
or matched by pgrep.
Reviewed by: gad, pjd
MFC after: 1 week
using my own script to handle it. I wrote my own partially because
of all the quoting-issues involved with testing what I wanted to test,
and partially because this lets me commit one script and one data file,
instead of one-file-per-regression-test.
This suite was good enough for my initial testing (and it did help me
find a few bugs that would have otherwise been missed). I'm not sure
how well it will work in general use, but I figured I might as well
commit it. It won't *hurt* to have it available. At the worst, people
can just ignore it.
Approved by: re (blanket `env')
so that make(1) will run in an almost clean environment and enhance the
description of the test infrastructure.
Add the ability to have multiple tests carried out per test script.
Give some tests more meaningful names.
Fix the usage message from the test scripts.
Make it possible to pass several commands to the test scripts like:
'sh test.t setup run compare clean'.
shell meta characters it is not passed to the shell, but the command
is executed directly (given that the line is not a shell builtin) and
that the line with a meta character is passed to the shell.
and adjust the path in the Makefile for the upgrade_checks target.
These checks are really feature upgrade checks that should be fast
and just find out whether we need to build a new make before
proceeding with other targets like buildworld. This makes the
place free for a real regression test suite in the old place.
by forcing the creation of an object directory for the make regression
tests. Let make handle the tracking of the dependency and installation
of test_shell script.
Submitted by: ru
that you create one of the object directories make knows (see make(1)).
This uses the -C flag, so add a test that checks that make actually accepts
-C. Also fix the test that selects csh via the .SHELL target to work for
tcsh users too.
This commit renames shell_test to shell_test.sh. There is no history
to preserve so go without a repo-copy.
Reviewed by: ru
understood by Perl's Test::Harness module and prove(1) commands.
Update README to describe the new protocol. The work's broken down into
two main sets of changes.
First, update the existing test programs (shell scripts and C programs)
to produce output in the ok/not ok format, and to, where possible, also
produce a header describing the number of tests that are expected to be
run.
Second, provide the .t files that actually run the tests. In some cases
these are copies of, or very similar too, scripts that already existed.
I've kept the old scripts around so that it's possible to verify that
behaviour under this new system (in terms of whether or not a test fails)
is identical to the behaviour under the old system.
Add a TODO file.
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
warning: duplicate script for target "double" ignored
The regression-tests do try to hide that message, but the message does
still appear when using -j (eg: 'make -j5 buildworld'). This changes the
regression-test so the expected warning message will not be seen even
when -j is specified.
Reviewed by: jmallett ru
