_features.txt

一个通讯程序源码

.*s 2 "Online Interactive Command Help"

The ECU help command presents a display of interactive commands.  The user
is then prompted to enter a command name for further, Unix-style
"usage" information.

.*s 2 "Multiscreen Event Alarm"

On an SCO machine, by using the 
.B BN
(bell notify) interactive command, an audible alert is sent to all
multiscreens when an ASCII BEL (bell) is received or when a file
transfer completes.  An additional option causes an alert when ANY
data is received from the line.  This makes it simple to do work on
other multiscreen consoles and be alerted when attention to the
communications session is required.

For instance, the Berkeley 4.x Unix utility "talk" rings the bell when
another user wishes an interactive chat mode.  BSD "biff" rings the bell
when incoming mail is received.  Scripts or commands at remote sites can
be configured to ring the bell as in:
.DS I
make foo bar; bell; make more_stuff; bell;
.DE
to call attention to the ECU user when work is being done
on other multiscreen consoles.

This feature is only available when you are running ECU from a multiscreen.

.*s 2 "Built-in Modem Dialer"

The built-in ECU dialer supports modems which use the 
.B
Hayes-style AT command set or most variants
.R
.B thereof .
It is used when HoneyDanBer UUCP is not installed or when there is no
entry in the /usr/lib/uucp/Devices file for the selected outgoing line.
(For more information, see the later section titled "HoneyDanBer UUCP
Interface".)

The built-in dialer uses files in the ecu library directory which
contains modem initialization information.  Modem initialization
filenames are made from concatenating the tty name with ".mi".  For
instance, tty1a's initialization file is named "tty1a.mi".

Commands for initializing the modem and for dialing may be specified in
a very flexible manner.  Separate init and dial strings for each legal
baud rate, a single pair of strings for all baud rates or a combination
may be specified.
.DF L
.hl
.ce 1
Sample Modem Initialization Files

#+-----------------------------------------------------------
#  tty1a.mi - Microcom AX/9624c
#------------------------------------------------------------
init_>2400:ATS11=47X4S0=0S7=30\eQ1\eX1\eN3   # baud rates > 2400
init_default:ATS11=47X4S0=0S7=30\eQ0\eX0\eN0 # other baud rates
dial_default:ATDT

#+-----------------------------------------------------------
#  tty2d.mi - USR Courier 2400
#------------------------------------------------------------
init_default:ATS11=47 X4 S0=0 S7=32
dial_default:ATDT

.DE

.*s 2 "File Transfer"

ECU supports numerous file transfer protocols: as of this writing,
XMODEM, XMODEM/CRC, XMODEM-1K, YMODEM/CRC Batch, ZMODEM/CRC-16,
ZMODEM/CRC-32, C-Kermit and SEAlink are supported.  `
Although a seamless interface
(there's some yuppie marketing newspeak) is provided to the user,
transfer is facilitated by executing external programs.

Kermit support requires you to obtain C-Kermit version 5A or later.
You may also patch C-Kermit 4E to work with ECU (The
patch information is available in the ckermit subdirectory of the
ECU release).  C-Kermit 5 is in beta release as of this writing
and supports ECU without modification.

XMODEM, YMODEM and ZMODEM transfers (thanks to modified public domain
programs by Chuck Forsberg) present dynamic status displays similar to
the following:
.DS L
 .-[ ecusz 3.20 ]-- /tmp -------------------------------.
 |  ZMODEM/CRC32   data rate ~= 900 ch/sec (94%)     T  |
 |  File 1   of 1  : /t/ecu320cpio.Z                    |
 |  File position:  617472 length: 915263  -rw-r--r--   |
 |  Total transaction 915263 bytes (xfer time ~= 17:29) |
 |  tx: D32 ZCRCG 1024          rx: HEX ZACK  605184    |
 |  Comm I/O: rx 917       tx 650041   bytes            |
 |  Baud rate: 9600 BINARY blklen: 1024 comm mode: RAW  |
 |  Time: started: 13:39:34 this file: 13:39:35 window: |
 |  13:51:34 elapsed: 00:12:00         00:11:59 +12288  |
 |  Errors: this file: 2   total: 2  files skipped: 0   |
 |                                                      |
 |  This file 67%, transaction 67% complete             |
 |  Remote: CRC32 y  duplex y  continuous stream y      |
 `- Connected to tridom --------------------------------'
.DE

During file transfer, data rates are displayed from time to time.
While the figures may vary significantly during the transfer, bear in mind
the calculations are for actual data throughput, measured as total DATA
characters transferred from the time the file is opened until it is closed.
So, if the data rate appears to be low at the start of the transfer
and increase over time, perhaps it took a significant amount of time for
the receiver to open it's file or to respond to protocol startup stimuli.
If the data rate appears to be higher at the beginning and become
lower over time, perhaps flow control is being invoked.  A sudden
reduction in the "last file" or "transaction" data rate over the
in progress rate reflects the time required to close files, operate
the protocol or to skip files (in the case of ZMODEM).  If any files
are skipped in a session, you may be sure the transaction
rate will be (perhaps much) lower than the per-file rate.

On some systems and driver options, sundry driver statistics are
displayed during X/Y/ZMODEM transfers.  For instance, in the above
display from a Sun session.  the driver's current output and input
queue depths and input queue space available are displayed along with
the current status of RTS and CTS.  While such gay banter is rightly
relegated to the "bell and whistle" category, it does provide a rare
insight into driver operation.  The ECU FAS/i driver for 386 systems
(after Uwe Doering's FAS driver) provides other information.

.DS L
        |  Output queue depth       0  RTS T  CTS T                |
        |  Input queue depth       10  Input queue avail    490    |
.DE


.*s 2 "Automatic ZMODEM Receive"
ECU in the interactive mode (no procedure executing) can interpret a
SUB, 'B', '0', '0' receive data sequence as a ZMODEM ZRQINIT frame and
automatically begin a ZMODEM receive operation.  The
.B autorz
interactive and procedure commands control
this feature.  By default, this feature is turned on.

.*s 2 "Procedures (Scripts)"
A powerful, language-style procedure language is incorporated
into ECU.  The language is described in the companion "Procedure
Language" manual.

Procedures are files of programmatic instructions written in
the ECU procedure language invoked explicitly by the
.B do 
interactive command or automatically by ECU functions described below.
Procedures are invoked by
.I name ,
and result in execution of the file
.I name .ep.

The file is searched for in the current directory.  If not found there,
ECU checks your personal .ecu subdirectory.  If not there, the ECU library "ep" subdirectory is searched (e.g.,
.I /usr/local/lib/ecu/ep ).

.*s 3 "Initial (Startup) Procedure"
An
.B
initial procedure
.R
may be be specified to ECU either to initialize an interactive
session or to execute an entirely unattended or "batch"
communication session.  Refer to the section on command switches ("-p").

.*s 3 "Dialing Procedure"
When a named dialing entry is selected for calling, if a procedure
can be located using the above mentioned search sequence whose name matches
the name of the directory, then all of the usual ECU built-in dialing
procedure is bypassed and the procedure is used.  For details, refer to
other sections related to dialing.
.*s 3 "Other Special Procedures"
Other special procedures may be invoked when
.BL
.LI
ecu starts up (_rc.ep)
.LI
a connection is established (_connect.ep)
.LI
an attempted connection fails (_connfail.ep)
.LI
a connection is terminated with the hangup command (_hangup.ep)
.LE
See the ECU procedure manual for details.

.*s 2 "DCD (Carrier) Watcher"
ECU can be instructed to monitor DCD (carrier) status on any
tty line whose driver honors dynamic manipulation of the CLOCAL
control bit.  
ECU may be instructed to ignore DCD (the default state).
In such a state, if carrier is lost after a connection has been
made, ECU is unaware the connection has been lost.  An interactive
.B stat
command will show the connection still active.

When the DCD watcher is enabled, loss of carrier will cause
the hangup command processing to automatically be executed
(including execution of the special procedure
_hangup.ep if any can be found).

An additional mode is available which, in addition to the hangup
processing,  causes ecu to terminate execution.

The
.B dcdwatch
interactive and procedure commands control this feature.
In addition, each dialing directory entry has a field
specifying whether or not the DCD watcher status is to be
changed upon connecting to the remote system and if so,
to what state.  Refer to the description of the
.B dcdwatch
and
.B dial
commands for details.

.*s 2 "Home Directory Files"
ECU control files reside in the .ecu subdirectory of
each user's home directory.  For example, in home directory /usr/wht:
.DS I
   /usr/wht/.ecu/dir          CD interactive command history file
*  /usr/wht/.ecu/keys         function key mapping
*  /usr/wht/.ecu/funckeymap  function key mapping
   /usr/wht/.ecu/log          connect, file transfer history
   /usr/wht/.ecu/phone        default dialing directory
*% /usr/wht/.ecu/colors       colors used by ECU
.DE

* The ecu library directory (normally /usr/local/lib/ecu) is searched for
the "keys", "colors" and "funckeymap" file if a personal version
cannot be found.

% The "colors" file does not apply to systems on which color is not yet
supported.

The .ecu directory is searched for an ECU procedure file
(having the '.ep' extension) if the procedure file cannot be found in
the current working directory.

.*s 2 "Lock Files"

ECU maintains lock files in the standard directory in accordance with the
HoneyDanBer UUCP conventions (ASCII pids as 10-character strings
followed by a newline).  If porting to a machine with old-style
integer pids, grep for HONEYDANBER in the sources for hints on
where changes are needed.

Standard lock directories for versions supported as of this writing:
.DS I
   SCO               /usr/spool/uucp
   ISC               /usr/spool/locks
   SunOS, SVR4       /var/spool/locks
.DE

.ul 1
World write access to this directory must be in effect. 

See the later section titled "HoneyDanBer UUCP Interface".

.*s 2 "Dial-In/Dial-Out Line Support"

On SCO XENIX and UNIX 3.2 systems,
ECU works with the SCO getty to support dialing out on a line
enabled for login.  After use of the line is complete,
ECU signals the system to restore incoming call status to
the line.
See the later section titled "HoneyDanBer UUCP Interface".

This facility is not supported in other environments as of this writing.
Scan the distribution README.* files for any updates.

.*s 2 "Tools"

Commands are provided for conversion of hexadecimal or decimal numbers
to and from ASCII equivalents.  For example, 26(10) == 0x1a == ^Z == SUB.
For details, refer to the description of the
.B XA
and
.B AX
interactive commands.

.*s 2 "Shared Memory 'Friend' Interface"

ECU maintains a copy of the received screen image (80 x 43
maximum) and other
information in its shared memory segment.  Normally, this
information is used only by the transmitter and receiver
process.  However,  ECU supports the concept of a
.B friend
process which may access the shared memory segment, perform
arbitrary auxiliary operations, read from and write to the
attached communications line and communicate resulting information
or status to an ECU procedure via a 1024-byte "friend"
data area in the shared memory segment.

The procedure language supports the friend
process concept through commands and functions which allow
.BL
.LI
passing the ECU shared memory segment id (%shmid) to a called
program,
.LI
reading a single character or string of characters from
screen memory,
.LI
reading cursor position information and
.LI
reading and writing of characters, short or long integers and
strings in the 1024-byte "friend" shared memory data area.
.LE

The algorithm for obtaining the shared memory segment key is
.DS L
0xEC000000L + transmitter process id
.DE
Thus a "friend" process may either use a %shmid 
.B
shared memory key
.R
passed as an argument or obtain the 
.B
shared memory key
.R
by using:
.DS L
key_t shmkey = 0xEC000000L | getppid();
.DE

This facility allows batch and interactive applications
to be developed with C programs which would be
tedious or impractical to implement with procedure language alone.

For more information, refer to the shared memory header file
.B ecushm.h ,
the
.B ecufriend
subdirectory of the software release
and to the description of the
.B %shmid ,
.B %cury
and
.B %curx
procedure functions
and the
.B getf
and
.B putf
procedure commands.