ckermit.bwr

linux终端仿真程序

effect, especially if you do this on the receiving end; that's because a lot
of packets might already be on their way to you.  In that case, just be
patient and let Kermit "drain" them.

If C-Kermit is sending a file, remote-mode packet-mode breakout (Ctrl-C Ctrl-C
by default) is not effective until after C-Kermit sends its first packet.  If
C-Kermit is receiving a file or is in server mode, it will be effective right
away.  In the former case, the SET DELAY value determines the earliest time at
which you can break out of packet mode.

Some communication programs have errors in their implementation of Kermit
attribute packets.  If you get an error message from your communication
program like "Attribute error", tell C-Kermit to SET ATTRIBUTES OFF.  Better
yet, switch to a real Kermit program, such as MS-DOS Kermit.

When using C-Kermit to transfer files with the HP48SX calculator, you must
SET FLOW NONE.  The HP48SX does not support flow control, and evidently also
becomes confused if you attempt to use it.

Occasionally, when receiving files in remote mode using a large window
size, attempts to cancel a file (X) can take a long time.

The fullscreen file transfer display will not work right if your terminal type
is set incorrectly, or is not known to the host operating system.  Even when
it does work, it might slow down your file transfers a bit, especially on
high-speed network connections.  On certain small computers, it has been
reported to cause increased disk activity due to swapping or paging.  The
fullscreen display is not particularly useful with speaking or Braille devices.
In these cases, use SET FILE DISPLAY CRT or SET FILE DISPLAY SERIAL.

If you have trouble transferring files over a TCP/IP connection, give the
command:

  SET PARITY SPACE

and try again.  If that doesn't work, also try a shorter packet length.

On the other hand, if file transfers through a TCP/IP connection work, but are
very slow, use a longer packet length, 2000 or more, and also try increasing
the window size.  Also, make sure FLOW is NONE since TCP/IP handles flow
control itself, and XON/XOFF processing only slows things down.

Some communication software claims to implement sliding windows, but does so
incorrectly.  If sliding window transfers fail, set C-Kermit's window size to
the smallest one that works, for example:

  SET WINDOW 1

The UNIX version of C-Kermit discards carriage returns when receiving files
in text mode.  Thus, "bare" carriage returns (sometimes used to achieve
overstriking) are lost.

SET FILE COLLISION BACKUP is the default.  This means:

 - If you send the same file lots of times, there will be many backup files.
   There is no automatic mechanism within Kermit to delete them, no notion of
   a "version retention count", etc.

 - If a file arrives that has the same name as a directory, the file transfer
   fails.  Send the file with another name, or use SET FILE COLLISION RENAME.

SET FILE COLLISION UPDATE depends on the date/time stamp in the attribute
packet.  However, this is recorded in local time, not GMT, and there is no
indication of time zone.  The time is expressed to the precision of 1 second,
but some file systems do not record with this precision -- for example, MS-DOS
records the file date/time only to the nearest 2 seconds.  This might cause
update operations to send more files than necessary.

SET FILE COLLISION OVERWRITE is risky, use it with caution.  Under certain
conditions, the existing file can be deleted even if the incoming file is
refused.

When C-Kermit is receiving files from another Kermit program that has been
given the MAIL or REMOTE PRINT command, C-Kermit follows the current filename
collision action.  This can be disconcerting if the action was (for example)
BACKUP, because the existing file will be renamed, and the new file will be
mailed (or printed) and then deleted.  Kermit cannot temporarily change to
RENAME because the file collision action occurs when the filename packet is
received, and the PRINT or MAIL disposition only comes later, in the Attribute
packet.

The STATISTICS command will produce an incorrect efficiency report if (a) it
does not know the true communication speed (e.g. on a network connection), or
(b) it knows the true serial interface speed to a modem, but the modem is
using a different communication speed with the other modem.  Similarly, in
these circumstances, C-Kermit's automatic calculation of the packet timeout
interval might also be incorrect, which can cause file transfers to fail.  One
solution to the latter problem is to SET SEND and RECEIVE TIMEOUT to
appropriate values for your true communication speed and packet length.

TELNET option negotiations are not handled during file transfer.  So far, no
ill effects have been noted.

Why is Kermit file transfer over a TCP/IP connection slower than FTP?  Because
the Kermit program on the remote end of the connection is not running directly
on a TCP socket, but rather running underneath a TELNET server, usually on a
pseudoterminal and under a login shell, with the vast amounts of per-character
overhead all of that implies.  Future Kermit releases will be able to act
directly as TCP servers, eliminating all this overhead.

Execution of multiple file transfers by C-Kermit from a command file when
in remote mode might exhibit long delays between each transfer.  To avoid
this, just include the command "SET DELAY 0" in your command file before any
of the file-transfer commands.


(13) SCRIPT PROGRAMMING

The CKERMIT.INI file that was originally distributed with C-Kermit 5A(188)
and (189) contained a nonfunctional CISLOGIN (CompuServe Login) macro.
Fixed in CKERMIT.INI dated September 2, 1993, or later.

Remember that ";" and "#" introduce comments when (a) they are the first
character on the line, or (b) they are preceded by at least one blank or
tab.  Thus constructions like:

  INPUT 5 ;
  SCRIPT ~0 #--#--# 

must be coded using backslash notation to keep the data from being ignored:

  INPUT 5 \59			; 59 is the decimal ASCII code for ";"
  SCRIPT ~0 \43--#--#		; 43 is the decimal ASCII code for "#"

or, more simply:

  INPUT 5 \;                    ; Just quote the semicolon
  SCRIPT ~0 \#--#--#            ; Just quote the "#"

INPUT and REINPUT caseless string comparisons do not work for non-ASCII
(international) characters.  Workaround: SET INPUT CASE OBSERVE.  Even then,
the "lexically less than" and "lexically greater than" operations (IF LLT, IF
LGT) probably won't work as expected.  The same is true for the
case-conversion functions \Flower() and \Fupper().  C-Kermit does not know the
collating sequence for different character sets and languages.  (On the other
hand, it might work depending on such items as how Kermit was linked, whether
your operating supports "locales", etc)

You can't include a NUL character (\0) in C-Kermit command text without
terminating the character string in which it appears.  For example:

  echo In these brackets [\0] is a NUL

will echo "In these brackets [".  This applies to ECHO, INPUT, OUTPUT, and all
other commands (but you can represent NUL by "\N" in an OUTPUT string).  This
is because C-language strings are terminated internally by the NUL character,
and it allows all of C-Kermit's string comparison and manipulation functions
to work in the normal "C" way.

To illustrate:
  INPUT 5 \0
is equivalent to:
  INPUT 5
and:
  INPUT 5 ABC\0DEF
is equivalent to:
  INPUT 5 ABC

INPUT operations discard and ignore NUL characters that arrive from the
communication device, meaning that they do not figure into matching operations
(e.g. A<NUL>B matches AB); they are not deposited in the INPUT buffer
(\v(input)); and they are not counted in \v(incount), with two exceptions:

  1. An arriving NUL character restarts the INPUT SILENCE timer.

  2. An arriving NUL character terminates the INPUT command with the
     SUCCESS condition if the INPUT command was given an empty search
     string.  In this case \v(incount) is set to 1.

Also, the \v(inchar) variable is null (completely empty) if the last INPUT
character was NUL.  That is, there is no way to tell only by looking at
\v(inchar) the difference between a NUL that was INPUT and no INPUT at all.
If the INPUT command succeeded but \v(inchar) is empty, then a NUL character
was input.  Also, \v(incount) will be set to 1.

\v(incount) and \v(inchar) are NOT affected by the CLEAR command.

GOTO can be used sort of like switch/case.  For example, if you know that the
value of \%a is 1, 2, or 3, you can "goto \%a" provided you have labels :1,
:2, and :3.  What it missing, however, is an automatic way to trap failing
GOTOs, similar to the "default:" clause of a C switch() statement.

The following script program:

  set count \ffiles(oofa.*)
  :loop
  send \fnextfile()
  if count goto loop

does not work as expected.  The SEND command (and any other command that
parses a filename, including TAKE) implicitly calls the same internal function
that \ffiles() calls, and thus destroys the file list set up in the first
line.  To accomplish this type of operation: (1) give the wild filespec to
\ffiles(); (2) loop through the file list and assign each filename to an array
element; (3) use the array of filenames in subsequent file-related commands.
Example:

  asg \%n \ffiles(\%1)
  declare \&f[\%n]
  for \%i 1 \%n 1 { asg \&f[\%i] \fnextfile() }
  for \%i 1 \%n 1 {
      send \&f[\%i]
  }

Certain settings are local to each command level, meaning that subordinate
command levels (macros or command files) can change them without affecting
their values at higher command levels.  When a new command level is invoked,
the value is inherited from the previous level.  These settings are:

  CASE
  COUNT and \v(count)
  INPUT CASE
  INPUT TIMEOUT
  MACRO ERROR
  TAKE ERROR

This arrangement allows CASE, TIMEOUT, and ERROR settings, which are used to
control automatic exit from a command file or macro upon error, to be
automatically restored when the command file or macro exits.

The COUNT variable follows this rule too, which permits nested SET COUNT /
IF COUNT loops, as in this example in which the inner loop counts down from
the current COUNT value of the outer loop (try it):

  DEFINE INNER WHILE COUNT { WRITE SCREEN {   Inner:}, SHOW COUNT }
  SET COUNT 5
  WHILE COUNT { WRITE SCREEN Outer:, SHOW COUNT, DO INNER }

Keep in mind that an inferior command level cannot manipulate the COUNT
value held by a higher level.  For example:

  DEFINE OOFA SHOW COUNT, IF COUNT GOTO LOOP
  SET COUNT 5
  :LOOP
  OOFA
  ECHO Done

results in an infinite loop; the COUNT value remains at 5 because it is never
decremented at the same level at which it was set.

NOTE: "WHILE COUNT" did not work prior to edit 095 of ckuusr.c, 19 Jan 93.

(End of CKERMIT.BWR)