ckubwr.txt

C-Kermit源码。是使用串口/Modem和网络通讯的程序

CKUBWR.TXT         "Beware File" for C-Kermit Version 7.0         -*- text -*-

			      C-KERMIT FOR UNIX


As of C-Kermit version:  7.0.197
This file last updated:  8 February 2000


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

  Copyright (C) 1985, 2000,
    Trustees of Columbia University in the City of New York.
    All rights reserved.  See the C-Kermit COPYING.TXT file or the
    copyright text in the ckcmai.c module for disclaimer and permissions.

WHAT IS IN THIS FILE

This is the "beware file" for the UNIX version of C-Kermit.  It contains hints
and tips, frequently asked questions (and answers), troubleshooting advice,
limitations and restrictions, known bugs, unresolved reports, etc, that apply
to all UNIX variations, as well as to specific ones like HP-UX, AIX, Solaris,
SunOS, Unixware, NeXTSTEP, etc etc.

This file should be read in conjunction with the system-independent C-Kermit
beware file, ckcbwr.txt, which contains similar information, but applying to
all versions of C-Kermit (VMS, OS/2, AOS/VS, VOS, etc, as well as to UNIX).


CONTENTS

  (0)  DOCUMENTATION AND TECHNICAL SUPPORT
  (0.1)  THE C-KERMIT USER MANUAL
  (0.2)  TECHNICAL SUPPORT
  (0.3)  THE YEAR 2000
  (0.4)  THE EURO SYMBOL
  (1)  IMPORTANT FILES
  (2)  BINARIES
  (3)  NOTES ON SPECIFIC UNIX VERSIONS
  (3.0)  C-KERMIT ON PC-BASED UNIXES
  (3.1)  C-KERMIT AND AIX
  (3.2)  C-KERMIT AND HP-UX
	 3.2.0. Common Problems
	 3.2.1. Building C-Kermit on HP-UX
	 3.2.2. Performance
	 3.2.3. Dialing Out and UUCP Lockfiles in HP-UX
	 3.2.4. HP-UX 5.00
	 3.2.5. HP-UX 8.00
	 3.2.6. HP-UX 9.00 AND LATER
	 3.2.7. HP-UX 10.10 AND LATER
	 3.2.8. HP-UX and X.25
  (3.3)  C-KERMIT AND LINUX
	 3.3.1. Problems Building C-Kermit for Linux
	 3.3.2. Problems with Serial Devices in Linux
	 3.3.3. Terminal Emulation in Linux
	 3.3.4. Dates and Times
         3.3.5. Startup Errors
  (3.4)  C-KERMIT AND NEXTSTEP
  (3.5)  C-KERMIT AND QNX
  (3.6)  C-KERMIT AND SCO UNIX, XENIX, ODT, AND OPENSERVER
  (3.7)  C-KERMIT AND SOLARIS
  (3.8)  C-KERMIT AND SUNOS
  (3.9)  C-KERMIT AND ULTRIX
  (3.10) C-KERMIT AND UNIXWARE
  (3.11) C-KERMIT AND APOLLO SR10
  (3.12) C-KERMIT AND TANDY XENIX 3.0
  (3.13) C-KERMIT AND OSF/1 (DIGITAL UNIX)
  (3.14) C-KERMIT AND SGI IRIX
  (3.15) C-KERMIT AND THE BEBOX
  (3.16) C-KERMIT AND DG/UX
  (3.17) C-KERMIT AND SEQUENT DYNIX
  (3.18) C-KERMIT AND {FREE,OPEN,NET}BSD
  (4)  GENERAL UNIX-SPECIFIC LIMITATIONS AND BUGS
  (5)  INITIALIZATION AND COMMAND FILES
  (6)  COMMUNICATION SPEED SELECTION
  (7)  COMMUNICATIONS AND DIALING
  (8)  HARDWARE FLOW CONTROL
  (9)  TERMINAL CONNECTION AND KEY MAPPING
  (10) FILE TRANSFER
  (11) EXTERNAL FILE TRANSFER PROTOCOLS
  (11.1) C-KERMIT AS AN EXTERNAL PROTOCOL
  (11.2) INVOKING EXTERNAL PROTOCOLS FROM C-KERMIT
  (11.3) USING C-KERMIT WITH TERM
  (12) SECURITY
  (13) MISCELLANEOUS USER REPORTS
  (14) THIRD-PARTY DRIVERS


(0) DOCUMENTATION AND TECHNICAL SUPPORT

(0.1) THE C-KERMIT USER MANUAL

C-Kermit is documented in the book "Using C-Kermit" by Frank da Cruz and
Christine M. Gianone, Digital Press, Burlington, MA, USA, ISBN 1-55558-164-1.
Price: US $44.95.  To order, call Columbia University, New York City, at
[phone], or Digital Press / Butterworth-Heinemann at:

  [phone]  (Massachusetts office for USA & Canada)
  [phone] (Rushden, England office for Europe)
  [phone]   (Chatswood, NSW, office for Australia & New Zealand)
  [phone]     (Singapore office for Asia)

Or visit the Kermit website at http://www.columbia.edu/kermit/.

A German edition is available from Verlag Heinz Heise in Hannover, Germany,
Tel. [phone], Fax. [phone].

If you do not have the manual, please purchase it.  It explains how to use
C-Kermit, from getting started through advanced use and scripting, and sales
of the manual are the primary source of funding for C-Kermit development and
support.

New features added since "Using C-Kermit", 2nd Ed, was published are
documented in the ckermit2.txt file, which should be used as a supplement to
the manual until the 3rd edition is published.

(0.2) TECHNICAL SUPPORT

Please consult the manual, plus the ckcbwr.txt file and this file itself,
before submitting questions, reporting problems, etc, to:

  E-Mail: [e-mail]

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

    News: comp.protocols.kermit.misc

    Post: The Kermit Project
          Columbia University
          612 West 115th Street
          New York NY  10025-7799
          USA

    Fax: [phone]

Telephone support is also available:

  [phone], cost: $25.00 per call, payable via Visa or MC.

(0.3) THE YEAR 2000

The UNIX version of C-Kermit, release 6.0 and later, is "Year 2000 compliant",
but only if the underlying operating system is too.  Contact your UNIX
operating system vendor to find out which operating system versions, patches,
hardware, and/or updates are required.

As of C-Kermit 6.0, post-millenium file dates are recognized, transmitted,
received, and reproduced correctly during the file transfer process in
C-Kermit's File Attribute packets.  If post-millenium dates are not processed
correctly on the other end, file transfer will still take place, but the
modification or creation date of the received file might be incorrect.  The
only exception would be if the "file collision update" feature is being used
to prevent unnecessary transfer of files that have not changed since the last
time a transfer took place; in this case, a file might be transferred
unnecessarily, or it might not be transferred when it should have been.
Correct operation of the update feature depends on both Kermit programs having
the correct date and time.

Of secondary importance are the time stamps in the transaction and/or debug
logs, and the date-related script programming constructs, such as \v(date),
\v(ndate), \v(day), \v(nday), and perhaps also the time-related ones, \v(time)
and \v(ntime), insofar as they might be affected by the date.  The \v(ndate)
is a numeric-format date of the form yyyymmdd, suitable for both lexical and
numeric comparison and sorting: e.g. 19970208 or 20011231.  If the underlying
operating system returns the correct date information, these variables will
have the proper values.  If not, then scripts that make decisions based on
these variables might not operate correctly.

Most date-related code is based upon the C Library asctime() string, which
always has a four-digit year.  In UNIX, the one bit of code in C-Kermit that
is an exception to this rule is several calls to localtime(), which returns a
pointer to a tm struct, in which the year is presumed to be expressed as
"years since 1900".  The code depends on this assumption.  Any platforms that
violate it will need special coding.  As of this writing, no such platforms
are known.

Command and script programming functions that deal with dates use C-Kermit
specific code that always uses full years.

(0.4) THE EURO SYMBOL

C-Kermit 7.0 and later support Unicode (ISO 10646), ISO 8859-15 Latin Alphabet
9, PC Code Page 858, Windows Code Pages 1250 and 1251, and perhaps other
character sets, that encode the Euro symbol, and can translate among them
as long as no intermediate character-set is involved that does not include
the Euro.


(1) IMPORTANT FILES

In addition to the published documentation, the following files are useful
in troubleshooting:

    ckaaaa.txt:     Overview, file naming conventions, list of files, etc.
    ckuins.txt:     Installation instructions for UNIX C-Kermit.
    ckccfg.txt:     C-Kermit program configuration information.
    ckcbwr.txt:     C-Kermit "beware file" for all platforms.
    ckubwr.txt:     C-Kermit "beware file" for UNIX (this file).
    ckcplm.txt:     C-Kermit program logic manual.
    ckermit2.txt:   User documentation for features added since 6.0.192, and
                    since the 2nd Edition of "Using C-Kermit" was published.
    ckcXXX.txt:     Program edit history for edit XXX, e.g. ckc196.txt.
    ckuker.mak:     (or makefile) Makefile for UNIX C-Kermit.
    ck[cuw]*.[chw]: Source code for UNIX C-Kermit.

Note that all of the *.txt files are renamed from their pre-7.0 names due
to Microsoft's usurpation of traditional text filetypes like .hlp and .doc
for its own purposes.


(2) BINARIES

It is often dangerous to run a binary C-Kermit (or any other) program built
on a different computer.  Particularly if that computer had a different C
compiler, libraries, operating system version, processor features, etc, and
especially if the program was built with shared libraries, because as soon as
you update the libraries on your system, they no longer match the ones
referenced in the binary, and the binary refuses to load when you run it,
in which case you'll see error messages similar to:

  Could not load program kermit
  Member shr4.o not found or file not an archive
  Could not load library libcurses.a[shr4.o]
  Error was: No such file or directory

(These samples are from AIX.)  To avoid this problem, we try to build C-Kermit
with statically linked libraries whenever we can, but many of the binaries are
contributed from elsewhere (after all, we don't have several hundred different
machines in-house to build them on), and in any case some platforms do not
even offer the option of static linking.

It is often OK to run a binary built on an earlier OS version, but it is
rarely possible (or safe) to run a binary built on a later one, for example
to run a binary built under SunOS 4.1.2 on a SunOS 4.1.1 system.  Sometimes
even the system-or-library patch/ECO level makes a difference.

A particularly insidious problem occurs when a binary was built on a version
of the OS that has patches from the vendor (e.g. to libraries); in most cases
you won't be able to run such a binary on an unpatched version of the same
platform.

When in doubt, build C-Kermit from the source code on the system where it is
to be run (if possible!).  If not, ask us for a binary specific to your
configuration.  We might have one, and if we don't, we might be able to find
somebody who will build one for you.


(3) NOTES ON SPECIFIC UNIX VERSIONS

The following sections apply to specific UNIX versions.

One thread that runs through many of them, and implicitly perhaps through all,
concerns the problems that occur when trying to dial out on a serial device
that is (also) enabled for dialing in.  The "solutions" to this problem are
many, varied, diverse, and usually gross, involving configuring the device for
bidirectional use.  This is done in a highly system-dependent and often
obscure manner, and the effects (good or evil) are also highly system-
dependent.  Many examples are given in the system-specific sections below.

An important point to keep in mind is that C-Kermit is a CROSS-PLATFORM,
PORTABLE program.  It was not designed specifically and only for your
particular UNIX version, or for that matter, for UNIX in particular at all.
It also runs on VMS, AOS/VS, VOS, and many other non-UNIX platforms.  All
the UNIX versions of C-Kermit share common i/o modules, with compile-time
#ifdef constructions used to account for the differences among the many UNIX
products and releases.  If you think that C-Kermit is behaving badly, or
missing something, on your particular UNIX version, you might be right -- we
can't claim to be expert in 700+ different platforms.  If you're a programmer,