Testing the Compilation
=======================

   If your system supports pseudo-terminals, and you compiled the code
to support the new style of configuration files (`HAVE_TAYLOR_CONFIG'
was set to 1 in `policy.h'), you should be able to use the `tstuu'
program to test the `uucico' daemon.  If your system supports STREAMS
based pseudo-terminals, you must compile tstuu.c with
`-DHAVE_STREAMS_PTYS'.  (The STREAMS based code was contributed by Marc
Boucher).

   To run `tstuu', just type `tstuu' with no arguments.  You must run
it in the compilation directory, since it runs `./uucp', `./uux' and
`./uucico'.  The `tstuu' program will run a lengthy series of tests (it
takes over ten minutes on a slow VAX).  You will need a fair amount of
space available in `/usr/tmp'.  You will probably want to put it in the
background.  Do not use `^Z', because the program traps on `SIGCHLD'
and winds up dying.  The `tstuu' program will create a directory
`/usr/tmp/tstuu' and fill it with configuration files, and create spool
directories `/usr/tmp/tstuu/spool1' and `/usr/tmp/tstuu/spool2'.

   If your system does not support the `FIONREAD' call, the `tstuu'
program will run very slowly.  This may or may not get fixed in a later
version.

   The `tstuu' program will finish with an execute file named
`X.SOMETHING' and a data file named `D.SOMETHING' in the directory
`/usr/tmp/tstuu/spool1' (or, more likely, in subdirectories, depending
on the choice of `SPOOLDIR' in `policy.h').  Two log files will be
created in the directory `/usr/tmp/tstuu'.  They will be named `Log1'
and `Log2', or, if you have selected `HAVE_HDB_LOGGING' in `policy.h',
`Log1/uucico/test2' and `Log2/uucico/test1'.  There should be no errors
in the log files.

   You can test `uuxqt' with `./uuxqt -I /usr/tmp/tstuu/Config1'.  This
should leave a command file `C.SOMETHING' and a data file `D.SOMETHING'
in `/usr/tmp/tstuu/spool1' or in subdirectories.  Again, there should
be no errors in the log file.

   Assuming you compiled the code with debugging enabled, the `-x'
switch can be used to set debugging modes; see the `debug' command for
details (see Debugging Levels.).  Use `-x all' to turn on all
debugging and generate far more output than you will ever want to see.
The `uucico' daemons will put debugging output in the files `Debug1'
and `Debug2' in the directory `/usr/tmp/tstuu'.  After that, you're
pretty much on your own.

   On some systems you can also use `tstuu' to test `uucico' against
the system `uucico', by using the `-u' switch.  For this to work,
change the definitions of `ZUUCICO_CMD' and `UUCICO_EXECL' at the top
of `tstuu.c' to something appropriate for your system.  The definitions
in `tstuu.c' are what I used for Ultrix 4.0, on which
`/usr/lib/uucp/uucico' is particularly obstinate about being run as a
child; I was only able to run it by creating a login name with no
password whose shell was `/usr/lib/uucp/uucico'.  Calling login in this
way will leave fake entries in `wtmp' and `utmp'; if you compile
`tstout.c' (in the `contrib' directory) as a setuid `root' program,
`tstuu' will run it to clear those entries out.  On most systems, such
hackery should not be necessary, although on SCO I had to su to `root'
(`uucp' might also have worked) before I could run
`/usr/lib/uucp/uucico'.

   You can test `uucp' and `uux' (give them the `-r' switch to keep
them from starting `uucico') to make sure they create the right sorts
of files.  Unfortunately, if you don't know what the right sorts of
files are, I'm not going to tell you here.

   If you can not run `tstuu', or if it fails inexplicably, don't worry
about it too much.  On some systems `tstuu' will fail because of
problems using pseudo terminals, which will not matter in normal use.
The real test of the package is talking to another system.