Olaf Kirch - Linux Network Administrator Guide, Second Edition

Generally, using the speed option only should suffice. If you have only one serial device defined in port , uucico always picks the right one anyway, so you only have to give it the desired speed. If you have several modems attached to your systems, you still often don't want to name a particular port, because if uucico finds that there are several matches, it tries each device in turn until it finds an unused one.

We already encountered the login chat script, which tells uucico how to log in to the remote system. It consists of a list of tokens specifying strings expected and sent by the local uucico process. uucico waits until the remote machine sends a login prompt, then returns the login name, waits for the remote system to send the password prompt, and sends the password. Expect and send strings appear in alternation in the script. uucico automatically appends a carriage return character ( \r ) to any send string. Thus, a simple chat script would look like:

ogin: vstout ssword: catch22

You will probably notice that the expect fields don't contain the whole prompts. This ensures that the login succeeds, even if the remote system transmits Login: instead of login:. If the string you are expecting or sending contains spaces or other white-space characters, you must use quotes to surround the text.

uucico also allows for some sort of conditional execution. Let's say the remote machine's getty needs to be reset before sending a prompt. For this, you can attach a subchat to an expect string, set off by a dash. The subchat is executed only if the main expect fails, i.e., a timeout occurs. One way to use this feature is to send a BREAK if the remote site doesn't display a login prompt. The following example gives a general-purpose chat script that should also work in case you have to press Enter before the login appears. The empty first argument, ", tells UUCP to not wait for anything, but to continue with the next send string:

"" \n\r\d\r\n\c ogin:-BREAK-ogin: vstout ssword: catch22

A couple of special strings and escape characters can occur in the chat script. The following is a partial list of characters legal in expect strings:

""

The empty string. It tells uucico to not wait for anything, but to proceed with the next send string immediately.

\t

Tab character.

\r

Carriage return character.

\s

Space character. You need this to embed spaces in a chat string.

\n

Newline character.

\\

Backslash character.

On send strings, the following escape characters and strings are legal in addition to the above:

EOT

End of transmission character (^D).

BREAK

Break character.

\c

Suppress sending of carriage return at end of string.

\d

Delay sending for 1 second.

\E

Enable echo checking. This requires uucico to wait for the echo of everything it writes to be read back from the device before it can continue with the chat. It is primarily useful when used in modem chats (which we will encounter later). Echo checking is off by default.

\e

Disable echo checking.

\K

Same as BREAK .

\p

Pause for fraction of a second.

Sometimes you want to have multiple entries for a single system, for instance if the system can be reached on different modem lines. With Taylor UUCP, you can do this by defining a so-called alternate .

An alternate entry retains all settings from the main system entry and specifies only those values that should be overridden in the default system entry or added to it. An alternate is offset from the system entry by a line containing the keyword alternate .

To use two phone numbers for pablo , you would modify its sys entry in the following way:

system pablo

phone 123-456

.. entries as above ...

alternate

phone 123-455

system pablo phone 123-456… entries as above… alternate phone 123-455

When calling pablo , uucico will first dial 123-456, and if this fails, it will try the alternate. The alternate entry retains all settings from the main system entry and overrides the telephone number only.

Taylor UUCP provides a number of ways you may restrict the times when calls can be placed to a remote system. You might do this either because of limitations the remote host places on its services during business hours, or simply to avoid times with high call rates. Note that it is always possible to override call-time restrictions by giving uucico the -S or -f option.

By default, Taylor UUCP disallows connections at any time, so you have to use some sort of time specification in the sys file. If you don't care about call time restrictions, you can specify the time option with a value of Any in your sys file.

The simplest way to restrict call time is to include a time entry, followed by a string made up of a day and a time subfield. Day may be any combination of Mo, Tu, We, Th, Fr, Sa, and Su . You can also specify Any , Never , or Wk for weekdays. The time consists of two 24-hour clock values, separated by a dash. They specify the range during which calls may be placed. The combination of these tokens is written without white space in between. Any number of day and time specifications may be grouped together with commas, as this line shows:

time MoWe0300-0730,Fr1805-2200

This example allows calls on Mondays and Wednesdays from 3:00 a.m. to 7:30 a.m., and on Fridays between 6:05 p.m. and 10:00 p.m. When a time field spans midnight, say Mo1830-0600 , it actually means Monday, between midnight and 6:00 a.m. and between 6:30 p.m. and midnight.

The special time strings Any and Never mean what they say: calls may be placed at any or no time, respectively.

Taylor UUCP also has a number of special tokens you may use in time strings, such as NonPeak and Night . These special tokens are shorthand for Any2300-0800,SaSu0800-1700 and Any1800-0700,SaSu , respectively.

The time command takes an optional second argument that describes a retry time in minutes. When an attempt to establish a connection fails, uucico will not allow another attempt to dial up the remote host within a certain interval. For instance, when you specify a retry time of 5 minutes, uucico will refuse to call the remote system within 5 minutes after the last failure. By default, uucico uses an exponential backoff scheme, where the retry interval increases with each repeated failure.

The timegrade command allows you to attach a maximum spool grade to a schedule. For instance, assume you have the following timegrade commands in a system entry:

timegrade N Wk1900-0700,SaSu

timegrade C Any

This allows jobs with a spool grade of C or higher (usually mail is queued with grade B or C) to be transferred whenever a call is established, while news (usually queued with grade N) are transferred only during the night and at weekends.

Just like time, the timegrade command takes a retry interval in minutes as an optional third argument.

However, a caveat about spool grades is in order here. First, the timegrade option applies only to what your systems sends; the remote system may still transfer anything it likes. You can use the call-timegrade option to explicitly request it to send only jobs above some given spool grade; but there's no guarantee it will obey this request. [97] If the remote system runs Taylor UUCP, it will obey.