Change {atf,plain,tap}.test.mk to be internal implementation details of
bsd.test.mk. Makefiles that build tests should now only include bsd.test.mk
and declaratively specify what they want to build, without worrying about
the internal implementation of the mk files.
The reason for this change is to permit building test programs of different
interfaces from a single directory, which is something I had a need for
while porting tests over from src/tools/regression/.
Additionally, this change makes it possible to perform some other requested
changes to bsd.test.mk in an easier manner. Coming soon.
Redo r260506 by using the new TEST_METADATA functionality of bsd.test.mk
to mark the sh(1) and test(1) tests as not supporting root. This is to
get rid of hand-crafted Kyuafiles for these very simple cases.
MFC after: 5 days
One of the tests for test(1) fails and some of the tests for sh(1) are
silently bypassed when running as root.
To fix these tests and ensure they all run, mark the test programs for
sh(1) and test(1) as requiring an unprivileged user. (This should and
will be the default in Kyua but isn't yet.)
MFC after: 1 week
This change is a proof of concept on how to easily integrate existing
tests from the tools/regression/ hierarchy into the /usr/tests/ test
suite and on how to adapt them to the new layout for src.
To achieve these goals, this change:
- Moves tests from tools/regression/bin/<tool>/ to bin/<tool>/tests/.
- Renames the previous regress.sh files to legacy_test.sh.
- Adds Makefiles to build and install the tests and all their supporting
data files into /usr/tests/bin/.
- Plugs the legacy_test test programs into the test suite using the new
TAP backend for Kyua (appearing in 0.8) so that the code of the test
programs does not have to change.
- Registers the new directories in the BSD.test.dist mtree file.
Reviewed by: freebsd-testing
Approved by: rpaulo (mentor)
This reverts commit r247274.
As maintainer of sh, I disapprove of this feature addition.
It is too specific and can be done without easily using find(1) or stat(1).
I will add some hints to the test(1) man page shortly.
In general, FreeBSD sh is not the place to invent new shell language
features. This is how it has been maintained and adding features randomly
does not work with that.
The new syntax (e.g. [ FILE1 -ntca FILE2 ]) looks cryptic to me.
access, birth, change and modify times of two files, instead of only
being able to compare modify times. The builtin test in sh(1) will
automagically acquire the same expansion.
Approved by: grog
MFC after: 2 weeks
For these simple utilities, it doesn't harm to make all global variables
static. In fact, this allows the compiler to perform better forms of
optimisation and analysis.
Convert the tests to the perl prove format.
Remove obsolete TEST.README (results of an old TEST.sh for some old Unices)
and TEST.csh (old tests without correct values, far less complete than
TEST.sh).
MFC after: 1 week
More precisely, this gives precedence to an interpretation not using the
'(', ')', '-a' and '-o' in their special meaning, if possible. For example,
it is now safe to write [ "$a" = "$b" ] and assume it compares the two
strings.
The man page already says that test(1) works this way, so does not need to
be changed.
Interpretation of input with more parameters tries a bit harder to find a
valid parse in some cases.
Add various additional test cases to TEST.sh.
PR: standards/133369
Approved by: ed (mentor)
"feature" doesn't seem to be in the standards or elsewhere, and
it is against what we are used to in C and sh(1), so put the
paragraph under BUGS.
Pointed out by: dougb
MFC after: 3 days
the mtimes of a file. (This is probably only useful if you have
vfs.timestamp_precision set to something nonzero).
PR: 39163
Submitted by: Hal Burch <hburch@lumeta.com>
MFC after: 2 weeks
Remove eaccess(2) absence workaround. Add eaccess(2) checks for FILRD,
FILWR, FILEX and FILEXIST cases.
We cannot MFC this because there is no eaccess(2) in -stable yet.
PR: bin/35076
Reviewed by: ru
Approved by: ru
after making test(1) a sh(1) builtin; sh(1) coredumps when you run
something like this:
sh -c 'test ! `true 1`'
The cause is that the test(1) code totally depends on the presence of
two extra cells at the end of argv that are filled with NULL's. The
reason why the bug hasn't been exposed would be because the C startup
code kindly prepares argv with some extra zeroed cells for a program.
I know this is not the best fix, but since there are argv++'s without
boundary checks everywhere, I'd rather patch it up like this
(preparing a copy of argv with extra NULL's) for the moment.
MFC after: 3 days
o Old-style K&R declarations have been converted to new C89 style
o register has been removed
o prototype for main() has been removed (gcc3 makes it an error)
o int main(int argc, char *argv[]) is the preferred main definition.
o Attempt to not break style(9) conformance for declarations more than
they already are.
o Change
int
foo() {
...
to
int
foo(void)
{
...
