ckermit.bwr

linux终端仿真程序

CKERMIT.BWR          "Beware File" for C-Kermit Version 6.0        -*- text -*-

As of C-Kermit version:  6.0.192
This file last updated:  Fri Sep  6 23:23:23 1996

Authors: Frank da Cruz and Christine M. Gianone, Columbia University.

  Copyright (C) 1985, 1996, Trustees of Columbia University in the City of New
  York.  The C-Kermit software may not be, in whole or in part, licensed or
  sold for profit as a software product itself, nor may it be included in or
  distributed with commercial products or otherwise distributed by commercial
  concerns to their clients or customers without written permission of the
  Office of Kermit Development and Distribution, Columbia University.  This
  copyright notice must not be removed, altered, or obscured.

Report problems, suggestions, fixes, etc, to Frank da Cruz:

  The Kermit Project
  Columbia University
  612 West 115th Street
  New York NY 10025-7799  USA
  Email: [e-mail]

C-Kermit 6.0 is documented in the book "Using C-Kermit" by Frank da Cruz and
Christine M. Gianone, Second Edition, 1997, Digital Press / Butterworth-
Heinemann, Woburn, MA, USA, ISBN 1-55558-164-1.  Price: US $39.95.  Available
in book and computer stores, or order by phone, call Columbia University at
[phone], or Butterworth-Heinemann at [phone].  A German edition
is available from Verlag Heinz Heise in Hannover, Germany.


WHAT IS IN THIS FILE

This is the "beware file" for C-Kermit.  It contains hints and tips,
frequently asked questions (and answers), troubleshooting advice, limitations
and restrictions, known bugs, etc, that apply to all C-Kermit variations.
This file is supplemented by a system-specific "beware file" for each major
system where C-Kermit runs:

  ckuker.bwr - All variations of UNIX: HP-UX, AIX, SCO, Solaris, etc.
  ckoker.bwr - IBM OS/2
  ckvker.bwr - Digital Equipment Corporation VMS and OpenVMS
  cklker.bwr - Stratus VOS
  ckdker.bwr - Data General AOS/VS
  ckmker.bwr - Apple Macintosh
  ckiker.bwr - Commodore Amiga
  cksker.bwr - Atari ST
  ck9ker.bwr - Microware OS-9
  ckpker.bwr - Bell Labs Plan 9

This file contains the following sections:

   (1) INCOMPATIBILE CHANGES IN VERSION 6.0
   (2) THE C-KERMIT COMMAND PARSER
   (3) MULTIPLE SESSIONS
   (4) NETWORK COMMUNICATION
   (5) THE SERVICES DIRECTORY
   (6) MODEMS AND DIALING
   (7) DIALING HINTS AND TIPS
   (8) TERMINAL SERVERS
   (9) TERMINAL EMULATION
  (10) KEY MAPPING
  (11) THE TRANSMIT COMMAND
  (12) FILE TRANSFER
  (13) SCRIPT PROGRAMMING


(1) INCOMPATIBILE CHANGES IN VERSION 6.0

This is not necessarily an exhaustive list.

 . Unless you tell C-Kermit otherwise, if a serial or network connection
   seems to be open, and you attempt to EXIT or to SET LINE or SET HOST or
   TELNET, C-Kermit warns you that an active connection appears to be open
   and asks you if you really want to close it.  If you do not want these
   warnings, add SET EXIT WARNING OFF to your customization file.

 . The default for SET { SEND, RECEIVE } PATHNAMES was changed from ON
   to OFF, to prevent unexpected creation of directories and depositing of
   incoming files in places you might not know to look.

 . The default for SET FILE INCOMPLETE was changed from DISCARD to KEEP to
   allow for file transfer recovery.

 . The default file-transfer block-check is now 3, rather than 1.

 . The default flow-control is now "auto" ("do the right thing"), not Xon/Xoff.

 . Backslash (\) is no longer a line continuation character.

 . Negative INPUT timeout now results in infinite wait, rather than 1 second.

(2) THE C-KERMIT COMMAND PARSER

When using the command-line processor ("kermit -l /dev/tty00 -b 19200", etc),
note that in some cases the order of the command-line options makes a
difference, contrary to the expectation that order of command-line options
should not matter.  In this case, the -b option must be given after the -l
option if it is to have any effect.

If you specify an alternate initialization file on the command line (using the
-y option) and the file doesn't exist or can't be opened, no error is reported.

In the interactive command parser:

 . VMS-style command editing (arrow keys, etc) is not supported.
 . EMACS- or VI-style command line editing is not supported.
 . Editing keys are hardwired (Ctrl-U, Ctrl-W, etc).

If you interrupt C-Kermit before it has issued its first prompt, it will exit.
This means that you cannot interrupt execution of the initialization file, or
of an "application file" (file whose name is given as the first command-line
argument), or of an alternative initialization file ("-y filename"), and get
to the prompt.  There is, however, one exception to this rule: you *can*
interrupt commands -- including TAKE commands -- given in the '-C "command
list"' command-line argument and -- if there were no action commands among the
command-line arguments -- you will be returned to the C-Kermit prompt.  So,
for example, if you want to start C-Kermit in such a way that it executes a
command file before issuing its first prompt, and you also want to be able to
interrupt the command file and get to the prompt, include a TAKE command for
the desired command in the -C argument, for example:

   kermit -C "take dial.scr"

Reportedly, if you attempt to interrupt Kermit while it is executing its
initialization file, and you do this rapidly enough, e.g. by sending a
constant stream of Ctrl-C's at a very high rate of speed, depending on the
underlying operating system (reported only on a couple versions of UNIX),
duplicate Kermit processes might be created -- cause unknown, cure unknown,
workaround: don't do it.

If you use the backslash (\) prefix to enter a control character, space, or
question mark into a command literally, the backslash disappears and is
replaced by the quoted character.  If it was a control character, it is shown
as a circumflex (^).  This allows editing (backspace, delete, Ctrl-W) to work
correctly even for control characters.

The only way to include a comma literally in a macro definition -- as opposed
to having it separate commands within the definition -- is to enter its ASCII
value (44) in backslash notation, e.g.:

  DEFINE ROWS MODE CO80\{44}\%1

If you quote special characters in a filename (e.g. in the SEND command),
filename completion may seem to work incorrectly.  For example, if you have a
file whose name is a*b (the name really contains an asterisk), and you type
"send a\\*<ESC>", the "b" will not appear, nor will Ctrl-R redisplay the
completed name correctly.  But internally the file name is recognized anyway.

Question-mark help does not work during execution of an ASKQ command.  The
question marks are simply accepted as text.

The maximum length for a variable name is 20 characters.  For array
declarations and references, that includes the subscript.  So, for example:

  \%a[\m(max_services)]

is one character too long (this can be changed by redefining the symbol VNAML
in ckuusr.h and recompiling C-Kermit).

Some other maximums to watch out for:      Symbol    Value Defined in
							         
 Nesting level for command files:           MAXTAKE      30  ckuusr.h
 Nesting level for macros:                  MACLEVEL     50  ckuusr.h
 Nesting level for FOR / WHILE loops:       FORDEPTH     10  ckuusr.h
 Number of macros:                          MAC_MAX     256  ckuusr.h
 Size of INPUT buffer:                      INPBUFSIZ   256  ckuusr.h
 Maximum files to match a wildcard:         MAXWLD   varies  ck?fio.c
 Filespecs in MSEND command:                MSENDMAX    100  ckuusr.h
 Length of MSEND or GET string:             FSPECL      300  ckuusr.h
 Length for GOTO target label:              LBLSIZ       50  ckuusr.h
 Number of characters in a command:         CMDBL      1024  ckucmd.h
 Number of chars in a field of a command:   ATMBL       256  ckucmd.h
 \fexecute() recursion depth limit:         CMDDEP       20  ckucmd.h

ASK and ASKQ strip leading and trailing spaces from what the user types.  This
happens way down deep in the command parser -- it's nothing special about ASK
and friends.  The only way around this that works in both C-Kermit and MS-DOS
Kermit is for the user (the one who is responding to the ASK prompt) to type
(the first) leading space as "\32" and the (final) trailing space as "\32".
In this example, the password begins with 2 leading blanks and ends with two
trailing blanks, and "Passwd:" is the ASK prompt:

 Passwd:\32 secret \32

Of course, the user could also type *all* blanks as \32.

In OUTPUT commands only, \B and \\B send a BREAK signal, and \L and \\L send a
Long BREAK signal, and \N and \\N send a NUL (ASCII 0).  BREAK and Long BREAK
are special signals, not characters, and NUL is a character that normally
cannot be included in a C string, since it is the C string terminator.

If you really want to output a backslash followed by a B, an L, or an N (as is
needed to configure certain modems, etc), use "output \\B".


(3) MULTIPLE SESSIONS

C-Kermit does not support multiple sessions.  When you SET LINE (or SET PORT,
same thing) to a new device, or SET HOST to a new host, the previous SET LINE
device or network host connection is closed, resulting in hangup of the modem
or termination of the network connection.  In windowing environments like
HP-VUE, NeXTSTEP, OS/2, etc, you can run separate copies of Kermit in different
windows to achieve multiple sessions.

To achieve multiple sessions through a single serial port (e.g. when dialing
up), you can install SLIP or PPP on your computer and then use C-Kermit's
TCP/IP support over the SLIP or PPP connection, assuming you also have
TCP/IP networking installed on your computer.

On UNIX systems that support the "term" program, you can establish a
connection to another UNIX system with C-Kermit and then achieve multiple
sessions using "term" client programs like trsh (see ckuker.bwr and the term
documentation for details).


(4) NETWORK COMMUNICATION

In multiuser operating systems such as UNIX and VMS, TCP/IP RLOGIN connections
are available only to privileged users, since "login" is a privileged socket.
And assuming you are allowed to use it in the first place, it is likely to
behave differently depending on what type of host you are rlogging in to, due
to technical reasons having to do with conflicting interpretations of RFC793
(Out-Of-Band Data) and Rlogin (RFC1122)...  "Specifically, the TCP urgent
pointer in BSD points to the byte after the urgent data byte, and an
RFC-compliant TCP urgent pointer points to the urgent data byte. As a result,
if an application sends urgent data from a BSD-compatible implementation to an
RFC-1122 compatible implementation then the receiver will read the wrong
urgent data byte (it will read the byte located after the correct byte in the
data stream as the urgent data byte)."  Rlogin requires the use of OOB data
while Telnet does not.  Therefore, it is possible for Telnet to work between
all systems while BSD and System V TCP/IP implementation are almost always a
bad mix.

On a TCP/IP TELNET connection, you should normally have PARITY set to NONE and
(except in VMS C-Kermit) FLOW-CONTROL also set to NONE.  If file transfer does
not work with these settings (for example, because the remote TELNET server
only gives a 7-bit data path), use SET PARITY SPACE.  Do not use SET PARITY
MARK, EVEN, or ODD on a TELNET connection -- it interferes with TELNET
protocol.

If echoing does not work right after connecting to a network host or after
dialing through a TCP/IP modem server, it probably means that the TELNET
server on the far end of the connection is executing the TELNET protocol
incorrectly.  After initially connecting and discovering incorrect echoing
(characters are echoed twice, or not at all), escape back, give the