A/UX: uucp and Mail Questions (9/94)


I am trying to write a script for an L.sys file that will let me connect to
a 3B2/1000 machine via ISN using uucp. The beginning of the script looks
like this:

"" ATD555-1212, expect nothing send dial string
2400 \\r\\r expect 2400 send two carriage returns

This is where the confusion starts. The carriage returns must be sent to
set the line characteristics (autobaud). When I manually use cu to
connect, the two carriage returns typed are not echoed, but a 4- or 5-line
banner is sent back.

When I call with the line

uucico -r1 -sLAB -x9

the chat dialog cranks up and the number is dialed. However, when the
modem answers, the 2400 is picked up by the script. The modem then flashes
the TX light. I assume this means the carriage returns are being sent.
However, the RX light never flashes and uucico hangs and eventually times
out.

I don't believe the Welcome header is being sent. I have tried

\\r,,\\r

and several variations, i.e., more carriage returns and a variety of commas
in various positions. I have a feeling that only one carriage return is
being sent. This carriage return does not echo, and the program waits
forever, because the header will not be sent.

1) Does uucico send characters one at a time and wait for the echo before
sending the next one? This would account for the hang, because the first
two carriage returns are munched by the autobaud mechanism.

2) If the answer to the above is yes, is there any workaround? I tried
\\e\\r\\r but got the same results.

3) Assuming I can finally get the carriage returns processed and cause the
header to be sent, do I have to process each line of the header with an
"expect-send" pair, or can I simply "expect" the tail of the last line
of the header?

I solved the problem of the autobaud not echoing characters. Recall that I
have to send several carriage returns to get the attention of the system
after I get the connect message from the modem. Instead of sending \\r\\r\\r
(only one of the carriage returns evidently get sent), I now send

\\r\\c "" \\r\\c "" \\r\\c

It looks like the above line sends one carriage return and expects nothing,
sends another carriage return and expects nothing, and sends one more
carriage return.

This seems to do the trick. The header comes flying by and I can then
negotiate into the nuucp login. Because I can send files to the machine
without any problem, uucp seems to work okay. However, mail does not seem
to work. I have tried:

mail name!user and
mailx name!user and
rmail name!user

After I exit the mail programs, nothing happens. There are no log files
created in the spool area, and the phone never goes off hook. It seems
like the letter drops into a black hole! If uucp works, why doesn't mail
work? (I am using ksh.)

Usually, people play trial-and-error on the "expect" and "send" strings in
the L.sys to find communication line (modem or other device)
characteristics, like "Connect", "Online", and other message outputs from
the modem. uucico sends the "expect-send" pair of strings to the remote
uucp host via the communication line. It depends on how the underlying
communication device behaves itself. For example, does it require a
carriage return or a new line or a couple of delays while in conversation
mode? Below are special characters often used in the "expect-send" string:

\\r CARRIAGE RETURN
\\d DELAY for one second
\\c NO NL (No New Line)

A delay (\\d) is sometimes needed for uucico to wait for the communication
line to complete its task before process the next string.

The "expected" and "send" string pairs are processed in that order. Yes,
you may grab the last line of the display message as the "expected" string.
For autobaud to work, you can try the "" \\r\\c "" \\r\\c "expect-send"
sequences.

If uucp works, it does not necessarily mean that the "mail" should work.
It depends on how the "sendmail" system is set up and configured. Is the
"sendmail" program up and running on both machines?

The /usr/spool/mqueue/syslog file should record the reason for the mail
problem. However, the /etc/syslogd daemon must be running to show the
sendmail activity.


Article Change History:
13 Sep 1994 - Reviewed.
31 Aug 1992 - Reviewed.

Support Information Services
Published Date: Feb 18, 2012