Q: The script just hangs. A: The easiest thing to do is to run the script with a timeout option. If you're running a series of tests by "make test", you can say "S2_TIMEOUT= make test" instead, where is the timeout value in microseconds. You could also investigate which branch "hangs" based on the debugging/logging information provided. If this doesn't help, you may have found a bug. Please see BUGS. Note that timeouts are quite expensive, don't use them if you don't need to. Q: Is there a way to activate the debug info printing to understand what exactly is going on? A: The s2.sh script calls s2 with debugging/logging options automatically. For the description of debugging files, please see the section `s2.sh script output files' of the README file. If you want to limit/increase debugging, please see the `DIAGNOSTICS' section in the `testing/scripts/s2.env' file. Q: The s2.sh script generates loads of debugging files filled with useless information which slows down execution. A: Run the script with --fast option or when running all tests in a directory, do `make fast' instead of `make test'. Another option is to limit the diagnostics information through the DG_* environment variables and s2 binary options. Finally, you can also compile s2 without diagnostics. Q: Why is `testing' directory in ${prefix}/share/doc/s2-? It's sick! A: I don't like it either. However, the testing directory contains a lot of examples, which really are documentation too and more importantly `template' directories which contain syntax of SRM 2.x calls (not documented by the s2.txt manual). Suggestions for a better approach are welcome.