1 # To be sourced by shell scripts in the test suite.
3 # This software is part of the SBCL system. See the README file for
6 # While most of SBCL is derived from the CMU CL system, the test
7 # files (like this one) were written from scratch after the fork
10 # This software is in the public domain and is provided with
11 # absolutely no warranty. See the COPYING and CREDITS files for
14 # Before sbcl-1.0.13 or so, we set up some environment variables to
15 # the absolute (POSIX) pathname naming the SBCL runtime, core, and
16 # home; but this runs afoul of the Bourne shell's repeated
17 # tokenization of its inputs, so now we use some shell functions.
21 # Make the shell bomb out whenever an unset shell variable is used.
22 # Note that scripts may toggle this if necessary.
25 # Initialize variables.
26 set -a # export all variables at assignment-time.
27 # Note: any script that uses the variables that name files should
28 # quote them (with double quotes), to contend with whitespace.
29 SBCL_HOME="$SBCL_PWD/../contrib"
30 SBCL_CORE="$SBCL_PWD/../output/sbcl.core"
31 SBCL_RUNTIME="$SBCL_PWD/../src/runtime/sbcl"
32 SBCL_ARGS="--noinform --no-sysinit --no-userinit --noprint --disable-debugger"
34 # Scripts that use these variables should quote them.
35 TEST_BASENAME="`basename $0`"
36 TEST_FILESTEM="`basename "${TEST_BASENAME}" | sed 's/\.sh$//'`"
37 TEST_FILESTEM="`echo "${TEST_FILESTEM}" | sed 's/\./-/g'`"
38 TEST_DIRECTORY="$SBCL_PWD/$TEST_FILESTEM-$$"
40 # "Ten four" is the closest numerical slang I can find to "OK", so
41 # it's the Unix status value that we expect from a successful test.
42 # (Of course, zero is the usual success value, but we don't want to
43 # use that because SBCL returns that by default, so we might think
44 # we passed a test when in fact some error caused us to exit SBCL
45 # in a weird unexpected way. In contrast, 104 is unlikely to be
46 # returned unless we exit through the intended explicit "test
49 # Shell scripts in this test suite also return 104, so we need a
50 # convention for distinguishing successful execution of SBCL in one of
53 # Any test that exits with status 1 is an explicit failure.
63 "$SBCL_RUNTIME" --core "$SBCL_CORE" $SBCL_ARGS "$@"
65 "$SBCL_RUNTIME" --core "$SBCL_CORE" $SBCL_ARGS
69 run_sbcl_with_core () (
74 "$SBCL_RUNTIME" --core "$core" "$@"
76 "$SBCL_RUNTIME" --core "$core" $SBCL_ARGS
80 # Most tests that run an SBCL have to check whether the child's exit
81 # status. Our convention is that SBCL exits with status
82 # $EXIT_LISP_WIN to indicate a successful run; but some tests can't do
83 # this (e.g., ones that end in S-L-A-D), or need to indicate some
84 # other ways of succeeding. So this routine takes a test name, the
85 # exit status of the child, and then an arbitrary number extra
86 # arguments that will be treated as status-code/message pairs for
87 # unusual successful ways for the inferior SBCL to exit. If the exit
88 # code of the SBCL isn't found in the status-codes, the calling script
89 # will exit with a failure code.
90 check_status_maybe_lose () {
94 if [ $status = $EXIT_LISP_WIN ]; then
95 echo "test $testname ok"
99 while [ $# -gt 0 ]; do
100 if [ $status = $1 ]; then
102 echo "test $testname ok $1"
109 if [ $lose = 1 ]; then
110 echo "test $testname failed: $status"
118 # Not every test needs to touch the file system, but enough do to have
119 # them consistently do so in subdirectories. Note that such tests
120 # should not change their exit action, or do so only very carefully.
121 use_test_subdirectory () {
122 mkdir "$TEST_DIRECTORY"
124 trap "cleanup_test_subdirectory" EXIT
127 cleanup_test_subdirectory () {
129 ( set -f; rm -r "$TEST_DIRECTORY" )