readme

使用Kermit协议传输文件的程序

is not effective in this case.  When the transfer is complete, you'll need
to instruct your emulator to return to its terminal screen.

4.3. Getting Files

If your terminal emulator supports Kermit autodownloads AND server mode, you
can use GET ("gkermit -g files...") rather than RECEIVE ("gkermit -r"), and
the rest happens automatically, as when G-Kermit is sending.


5. INTERRUPTING FILE TRANSFER

G-Kermit supports file and group interruption.  The method for interrupting
a transfer depends on your terminal emulator.  For example, while the
file-transfer display is active, you might type the letter 'x' to cancel the
current file and go on to the next one (if any), and the letter 'z' to
cancel the group.  Or there might be buttons you can click with your mouse.

When G-Kermit is in packet mode and your terminal emulator is in its
terminal screen, you can also type three (3) Ctrl-C characters in a row to
make G-Kermit exit and restore the normal terminal modes.


6. TEXT AND BINARY TRANSFER MODE

When sending files in binary mode, G-Kermit sends every byte exactly as it
appears in the file.  This mode is appropriate for program binaries,
graphics files, tar archives, compressed files, etc, and is G-Kermit's
default file-transfer mode when sending.  When receiving files in binary
mode, G-Kermit simply copies each byte to disk.  (Obviously the bytes are
encoded for transmission, but the encoding and decoding procedures give a
replica of the original file after transfer.)

When sending files in text mode, G-Kermit converts the record format to the
common one that is defined for the Kermit protocol, namely lines terminated
by carriage return and linefeed (CRLF); the receiver converts the CRLFs to
whatever line-end or record-format convention is used on its platform.  When
receiving files in text mode, G-Kermit simply strips carriage returns,
leaving only a linefeed at the end of each line, which is the Unix
convention.

When receiving files, the sender's transfer mode (text or binary)
predominates if the sender gives this information to G-Kermit in a Kermit
File Attribute packet, which of course depends on whether your terminal
emulator's Kermit protocol has this feature.  Otherwise, if you gave a -i or
-T option on the gkermit command line, the corresponding mode is used;
otherwise the default mode (binary) is used.

Furthermore, when either sending or receiving, G-Kermit and your terminal
emulator's Kermit can inform each other of their OS type (Unix in G-Kermit's
case).  If your emulator supports this capability, which is called
"automatic peer recognition", and it tells G-Kermit that its platform is
also Unix, G-Kermit and the emulator's Kermit automatically switch into
binary mode, since no record-format conversion is necessary in this case.
Automatic peer recognition is disabled automatically if you include the -i
(image) or -T (text) option.

When sending, G-Kermit sends all files in the same mode, text or binary.
There is no automatic per-file mode switching.  When receiving, however,
per-file switching occurs automatically based on the incoming Attribute
packets, if any (explained below), that accompany each file, so if the
file sender switches types between files, G-Kermit follows along.


7. PATHNAMES

When SENDING a file, G-Kermit obtains the filenames from the command line.
It depends on the shell to expand metacharacters (wildcards and tilde).

G-Kermit uses the full pathname given to find and open the file, but then
strips the pathname before sending the name to the receiver.  For example:

  $ gkermit -s /etc/hosts

results in an arriving file called "HOSTS" or "hosts" (the directory part,
"/etc/", is stripped; see next section about capitalization).

However, if a pathname is included in the -a option, the directory part
is not stripped:

  $ gkermit -s /etc/hosts -a /tmp/hosts

This example sends the /etc/hosts file but tells the receiver that its name
is "/tmp/hosts".  What the receiver does with the pathname is, of course, up
to the receiver, which might have various options for dealing with incoming
pathnames.

When RECEIVING a file, G-Kermit does NOT strip the pathname, since incoming
files normally do not include a pathname unless you told your terminal to
include them or gave an "as-name" including a path when sending to G-Kermit.
If the incoming filename includes a path, G-Kermit tries to store the file
in the specified place.  If the path does not exist, the transfer fails.
The incoming filename can, of course, be superseded with the -a option.


8. FILENAME CONVERSION

When sending a file, G-Kermit normally converts outbound filenames to
common form: uppercase, no more than one period, and no funny characters.
So, for example, gkermit.tar.gz would be sent as GKERMIT_TAR.GZ.

When receiving a file, if the name is all uppercase, G-Kermit converts it
to all lowercase.  If the name contains any lowercase letters, G-Kermit
leaves the name alone.  Otherwise G-Kermit accepts filename characters as
they are, since Unix allows filenames to contain practically any characters.

If the automatic peer recognition feature is available in the terminal
emulator, and G-Kermit recognizes the emulator's platform as Unix, G-Kermit
automatically disables filename conversion and sends and accepts filenames
literally.

You can force literal filenames by including the -P option on the command
line.


9. FILENAME COLLISIONS

When G-Kermit receives a file whose name is the same as that of an existing
file, G-Kermit backs up the existing file by adding a unique suffix to its
name.  The suffix is ".~n~", where n is a number between 1 and 999.  This
the same kind of backup suffix used by GNU EMACS and C-Kermit (both of which
can be used to prune excess backup files).  But since G-Kermit does not read
directories (see Implementation Notes below), it can not guarantee that the
number chosen will be higher than any other backup prefix number for the
same file.  In fact, the first free number, starting from 1, is chosen.  If
an incoming file already has a backup suffix, G-Kermit strips it before
adding a new one, rather than creating a file that has two backup suffixes.

To defeat the backup feature and have incoming files overwrite existing
files of the same name, include the -w (writeover) option on the command
line.

If G-Kermit has not been been given the -w option and it fails to create a
backup file, the transfer fails.


10. KERMIT PROTOCOL DETAILS

Block check
  G-Kermit uses the 3-byte, 16-bit CRC by default.  If the other Kermit
  does not agree, both Kermits automatically drop down to the single-byte
  6-bit checksum that is required of all Kermit implementations.

Attributes
  When sending files, G-Kermit conveys the file transfer mode and file
  size in bytes to the receiver in an Attribute (A) packet if the use of
  A-packets was negotiated.  This allows the receiver to switch to the
  appropriate mode automatically, and to display the percent done, estimated
  time left, and/or a thermometer bar if it has that capability.  When
  receiving, G-Kermit looks in the incoming A-packet, if any, for the
  transfer mode (text or binary) and switches itself accordingly on a
  per-file basis.

Handling of the Eighth Bit
  G-Kermit normally treats the 8th bit of each byte as a normal data bit.
  But if you have a 7-bit connection, transfers of 8-bit files fail unless
  you tell one or both Kermits to use the appropriate kind of parity, in
  which case Kermit uses single-shift escaping for 8-bit bytes.  Generally,
  telling either Kermit is sufficient; it tells the other.  Use the -p
  option to tell G-Kermit which parity to use.  Locking shifts are not
  included in G-Kermit.

Control-Character Encoding
  G-Kermit escapes all control characters when sending (for example,
  Ctrl-A becomes #A).  When receiving, it accepts both escaped and bare
  control characters, including NUL (0).  However, unescaped control
  characters always present a danger, so if uploads to G-Kermit fail, tell
  your terminal emulator's Kermit to escape most or all control characters
  (in C-Kermit and Kermit 95 the command is SET PREFIXING CAUTIOUS or SET
  PREFIXING ALL).

Packet Length
  All legal packet lengths, 40-9020, are supported although a lower
  maximum might be imposed on platforms where it is known that bigger ones
  don't work.  When receiving, G-Kermit sends its receive packet length to
  the sender, and the sender must not send packets any longer than this
  length.  The default length for most platforms is 4000 and it may be
  overridden with the -e command-line option.

Sliding Windows
  G-Kermit does not support sliding windows.  Streaming is used instead.
  If the other Kermit bids to use sliding windows, G-Kermit declines.

Streaming
  If the terminal emulator's Kermit informs G-Kermit that it has a
  reliable connection (such as TCP/IP or X.25), and the emulator's Kermit
  supports streaming, then a special form of the Kermit protocol is used
  in which data packets are not acknowledged; this allows the sender to
  transmit a steady stream of (framed and checksummed) data to the
  receiver without waiting for acknowledgements, allowing the fastest
  possible transfers.  Streaming overcomes such obstacles as long round
  trip delays, unnecessary retransmissions on slow network connections,
  and most especially the TCP/IP Nagle and Delayed ACK heuristics which
  are deadly to a higher-level ACK/NAK protocol.  When streaming is in use
  on a particular connection, Kermit speeds are comparable to FTP.  The
  drawback of streaming is that transmission errors are fatal; that's why
  streaming is only used on reliable connections, which, by definition,
  guarantee there will be no transmission errors.  However, watch out for
  the relatively rare circumstance in which emulator thinks it has a
  reliable connection when it doesn't -- for example a Telnet connection
  to a terminal server, and a dialout from the terminal server to the
  host.  Use the -S option on the command line to defeat streaming in such
  situations.

Using all defaults on a TCP/IP connection on 10BaseT (10Mbps) Ethernet from
a modern Kermit program like C-Kermit 7.0 or Kermit 95, typical transfer
rates are 150-500Kcps.


11. PROBLEMS, BUGS, ERRORS

If file transfers fail:

 . Make sure your terminal emulator is not unprefixing control characters;
   various control characters might cause trouble along the communication
   path.  When in doubt, instruct the file sender to prefix all control
   characters.

 . Make sure your Unix terminal is conditioned for the appropriate kind
   of flow control.

 . Use command-line options to back off on performance and transparency;
   use -S to disable streaming, -e to select a shorter packet length, -p
   to select space or other parity, -b to increase or disable the timeout,
   and/or establish the corresponding settings on your emulator.

When receiving files in text mode, G-Kermit strips all carriage returns,
even if they aren't part of a CRLF pair.

If you have a TCP/IP connection (e.g. Telnet or Rlogin) to Unix from a
terminal emulator whose Kermit protocol does not support streaming,
downloads from G-Kermit are likely to be as much as 10 or even 100 times
slower than uploads if the TCP/IP stack engages in Nagle or Delayed ACK
heuristics; typically, when your terminal emulator's Kermit protocol sends
an acknowledgment, the TCP stack holds on to it for (say) 1/5 second before
sending it, because it is "too small" to send right away.

As noted in Section 9, the backup prefix is not guaranteed to be the highest
number.  For example, if you have files oofa.txt, oofa.txt.~1~, and
oofa.txt.~3~ in your directory, and a new oofa.txt file arrives, the old
oofa.txt is backed up to oofa.txt.~2~, rather than oofa.txt.~4~ as you might
expect.  This is because gkermit lacks directory reading capabilities, for
reasons noted in Section 14, and without this, finding the highest existing
backup number for a file is impractical.

If you send a file to G-Kermit with streaming active when the connection is
not truly reliable, all bets are off.  A fatal error should occur promptly,
but if huge amounts of data are lost, G-Kermit might never recognize a single
data packet and therefore not diagnose a single error; yet your terminal
emulator keeps sending packets since no acknowledgments are expected; the
transfer eventually hangs at the end of file.  Use -S on G-Kermit's command
line to disable streaming in situations where the terminal emulator requests
it in error.

You can use G-Kermit's debug log for troubleshooting; this is useful mainly
in conjunction with the source code.  But even if you aren't a C programmer,
it should reveal any problem in enough detail to help pinpoint the cause of
the failure.  "gkermit -d" (with no action options) writes a short debug.log
file that shows the build options and settings.

The debug log is also a packet log; to extract the packets from it, use:

  grep ^PKT debug.log

Packets in the log are truncated to avoid wrap-around on your screen, and
they have the Ctrl-A packet-start converted to ^ and A to avoid triggering
a spurious autodownload when displaying the log on your screen.

In certain circumstances it is not desirable or possible to use -d to create
a log file called debug.log in the current directory; for example, if you
don't have write access to the current directory, or you already have a
debug.log file that you want to keep (or transfer).  In this case, you can
include a filename argument after -d:

  gkermit -d /tmp/testing.log -s *.c

(This is an exception to the rule that option arguments are not optional.)

If all else fails, you can contact the Kermit Project for technical support;
see:

  http://www.columbia.edu/kermit/support

for instructions.


12. BUILDING G-KERMIT

G-Kermit is written to require the absolute bare minimum in system services
and C-language features and libraries, and therefore should be portable to
practically any Unix platform at all with any C compiler.

The source files are:

  makefile   The build procedure
  gwart.c    Source code for a mini-lex substitute
  gproto.w   G-Kermit protocol state machine to be preprocessed by gwart
  gkermit.h  G-Kermit header file
  gkermit.c  G-Kermit main module and routines
  gcmdline.c G-Kermit command-line parser
  gunixio.c  Unix-specific i/o routines

A simple makefile is provided, which can be used with make or gmake.  There
are three main targets in the makefile:

  posix
    Build for any POSIX.1 compliant platform (termios).  This is the
    default target, used if you type "make" (or "gmake") alone.  This
    target works for most modern Unixes, including GNU/Linux, FreeBSD,
    OpenBSD, NetBSD, BSDI, HP-UX, Solaris, SunOS, Unixware, AIX, etc.

  sysv
    Build for almost any AT&T System V platform (termio).  Examples
    include AT&T Unix releases, e.g. for the AT&T 7300, HP-UX versions
    prior to 7.00.

  bsd
    Build for any BSD (pre-4.4) or Unix V7 platform (sgtty).  Examples
    include NeXTSTEP 3.x, OSF/1, and 4.3BSD or earlier.

Note that the target names are all lowercase; "posix" is the default target
(the one used if you just type "make").  If the build fails with a message
like:

  gunixio.c: 65: Can't find include file termios.h
  *** Error code 1

then try "make sysv" or "make bsd".  See the build list below for examples.

Some special build targets are also provided:

  sysvx
    Like sysv but uses getchar()/putchar() for packet i/o rather than
    buffered nonblocking read()/write(); this is necessary for certain
    very old System V platforms (see description of USE_GETCHAR below).

  stty
    When none of the other targets compiles successfully, try this one,
    which runs the external stty program rather than trying to use
    API calls to get/set terminal modes (system("stty raw -echo") and
    system("stty -raw echo")).