The chat script used in the preceding example is very simple. Chat scripts get much more complicated depending on the intended connection. The following sample chat scripts range from the simple to the complex:

in:--in: nuucp word: panzer
     Expect in: if not received, send a NULL string (newline)
     send nuucp
     expect word
     send panzer

“” @ Login:-@-login:-BREAK-login:-BREAK-login: uucp word: login
     expect nothing
     send @ (equivalent to BREAK)
     expect login: if not received, send BREAK, maximum of two times
     send uucp
     expect word:
     send login

“” \r\d\r\d login:-BREAK-login:-BREAK-login: anon
     expect nothing
     send newline
     delay
     send newline
     delay
     expect login: if not received, send BREAK, maximum of two times send
    anon

“” \r\d service: uucp login: mimi word: guesswho
     expect nothing
     send newline
     delay
     expect service
     send uucp
    expect login:
     send mimi
     expect word
     send guesswho

---

Warning:  When you use UUCP over TCP/IP, do not include BREAKs or other subexpect-subsend combinations. They are not needed and can often lead to problems in establishing a connection.

---

Now that you know how the System file is formatted, here are some additional examples. (Notice that these examples also include UUCP over TCP/IP. This configuration is described later in this chapter.)

sosco Any,15 TBIT 9600 14084291786 “”
 \r\d\r\d login:-BREAK-login:-BREAK-login: uusls
unilabs.org Any TBIT 1200 5551211 “” \r\d\r\d login: nuucp word: nothing
uunet.ca Any TBIT 19200 5551210U “”
 \r\d service: uucp login: mimi word: none
uunet.ca Any TCP,e Any - login: mimi word: none
sffoo Any STARLAN - sffoo in:—in: nuucp word: nuucp

Testing the Connection—Using uucico

Now that the Systems file is set up, it is important to verify that your configuration to this point is correct. The uucico command is used with the -x option to specify a debug level, or with the uutry (Uutry on some systems) command.

The most difficult part of working with uucico is interpreting its error messages. Sometimes their messages are Greek to even the most experienced system administrator. To test the connection and the uucico process, you can use the -x# option with uucico. This option prints debug information on-screen. The # is a debug level, ranging from 1 to 9, with 9 being the maximum amount of debugging information available. From implementation to implementation, the amount of information provided at various levels depends on how the programmers coded it when they modified UUCP for their vendor. The following debug output illustrates a terminal session:

chare@unilabs> /usr/lib/uucp/uucico -r1 -x9 -sbugs
conn(bugs)
Device Type bugs wanted
getto ret -1
Call Failed: DEVICE LOCKED
Conversation Complete: Status FAILED

The debug output displayed is created by using the option -x followed by a level number. The higher the number, the higher the level of debug information that is printed. As mentioned earlier, the highest value is 9. In the following example, the connection to the remote system named bugs failed because the device is locked, meaning someone else is using the device. The only recourse you have is to wait until the device is free. Another attempt at establishing communications with the remote system is shown in the following:

chare@unilabs> /usr/lib/uucp/uucico -r1 -x9 -sthumper
conn(thumper)
Device Type thumper wanted
getto ret -1
Call Failed: CAN’T ACCESS DEVICE
Conversation Complete: Status FAILED

Note that the preceding example displayed a different error message: CAN’T ACCESS DEVICE. To correct this problem, suspect that the owner and group owner for the associated device file is incorrect. For example, if the connection attempts to use /dev/tty16 when connecting, check the ownership using the ls -l command. If the owner is not uucp, the UUCP-related programs will not be able to open the device. Reviewing the permissions for the associated device using the ls -l command shows that the owner of the device file is root, not uucp. As a result, uucp couldn’t open the device. The following setup shows the next attempt at contacting the remote system:

chare@unilabs> /usr/lib/uucp/uucico -r1 -x9 -sbugs
conn(bugs)
Device Type bugs wanted
getto ret 6
expect: (“”)
got it
sendthem (DELAY
^MDELAY
^M^M)
expect: (login:)
^M^Jroot@bugs> ^M^J^M^Jroot@bugs> root@bugs> timed out
Call Failed: LOGIN FAILED
Conversation Complete: Status FAILED