2009-09-06 Stefano Lattarini <stefano.lattarini@gmail.com> (tiny change)
+ tests/README: warn about zsh incompatibilities.
+ * tests/README (User interface, Getting details from failures):
+ Explicitly state that every test is a "shell script", not just
+ a "script", and that it's run by `/bin/sh' by default.
+ * tests/README (User interface, Supported shells): New subsection,
+ telling about expected portability of the automake test scripts,
+ describing a zsh incompatibility (w.r.t. $0), and a workaround to
+ it (with the `--no-function-argzero' option).
+
testsuite: fix a minor glitch.
* tests/defs.in (exit trap): Use `$me', not `$as_me', as the
name of the current test (used in error messages).
uniprocessor system, due to unavoidable sleep delays, as
noted below).
+
Interpretation
--------------
Getting details from failures
-----------------------------
- Each test is a script. In a non-VPATH build you can run them
- directly, they will be verbose. By default, verbose output of
- a test foo.test is retained in the log file foo.log. A summary
- log is created in the file test-suite.log.
+ Each test is a shell script, and by default is run by /bin/sh.
+ In a non-VPATH build you can run them directly, they will be verbose.
+ By default, verbose output of a test foo.test is retained in the log
+ file foo.log. A summary log is created in the file test-suite.log.
- You can limit the set of files using the TESTS variable, and
- enable detailed test output at the end of the test run with the
- VERBOSE variable:
+ You can limit the set of files using the TESTS variable, and enable
+ detailed test output at the end of the test run with the VERBOSE
+ variable:
env VERBOSE=x TESTS='first.test second.test ...' make -e check
+Supported shells
+----------------
+
+ The test scripts are written with portability in mind, so that they
+ should run with any decent Bourne-compatible shell.
+
+ However, some care must be used with Zsh, since, when not directly
+ starting in Bourne-compatibility mode, it has some incompatibilities
+ in the handling of `$0' which conflict with our usage, and which have
+ no easy workaround. Thus, if you want to run a test script, say
+ foo.test, with Zsh, you *can't* simply do `zsh foo.test', but you
+ *must* resort to:
+ zsh --no-function-argzero foo.test
+
+ Note that this problem does not occur if zsh is executed through a
+ symlink with a basename of `sh', since in that case it starts
+ in Bourne compatibility mode. So you should be perfectly safe when
+ /bin/sh is zsh.
+
+
Reporting failures
------------------