Temporarily use -O1 until segfault with -O2+krb5+iksd is fixed

[ckermit.git] / ckuins.txt

   [1]The Columbia Crown The Kermit Project | Columbia University
   612 West 115th Street, New York NY 10025 USA o [2]kermit@columbia.edu
   ...since 1981
   [3]Home [4]Kermit 95 [5]C-Kermit [6]Scripts [7]Current [8]New [9]FAQ
   [10]Support

C-Kermit 9.0 Installation Instructions and Options for Unix

   [ [11]Contents ] [ [12]C-Kermit ] [ [13]Kermit Home ]

   Frank da Cruz
   The Kermit Project
   Columbia University

      As of C-Kermit version: 9.0.300, 30 June 2011
      This file last updated: Tue Jun 28 08:28:08 2011 (New York City
   time)

   IF YOU ARE READING A PLAIN-TEXT version of this document, it is a
   plain-text copy of a Web page. You can visit the original (and possibly
   more up-to-date) Web page here:

[14]http://www.columbia.edu/kermit/ckuins.html

CONTENTS

   [15]OVERVIEW
    1. [16]INTERNET QUICK START
    2. [17]INSTALLING FROM PACKAGES
    3. [18]INSTALLING PREBUILT BINARIES
    4. [19]BUILDING FROM SOURCE CODE
    5. [20]INSTALLING THE KERMIT FILES
    6. [21]INSTALLING UNIX C-KERMIT FROM DOS-FORMAT DISKETTES
    7. [22]CHECKING THE RESULTS
    8. [23]REDUCING THE SIZE OF THE EXECUTABLE PROGRAM IMAGE
    9. [24]UNIX VERSIONS
   10. [25]DIALING OUT AND COORDINATING WITH UUCP
   11. [26]RUNNING UNIX C-KERMIT SETUID OR SETGID
   12. [27]CONFIGURING UNIX WORKSTATIONS
   13. [28]BIZARRE BEHAVIOR AT RUNTIME
   14. [29]CRASHES AND CORE DUMPS
   15. [30]SYSLOGGING
   16. [31]BUILDING SECURE VERSIONS OF C-KERMIT 9.0
   17. [32]INSTALLING C-KERMIT AS AN SSH SERVER SUBSYSTEM

OVERVIEW

   [ [33]Top ] [ [34]Contents ] [ [35]Next ]

     WARNING: This document contains notes that have been accumulating
     since the mid 1980s. Many of the products and Unix versions
     mentioned here have not been heard of in a long while, but that does
     not necessarily mean they are not still running in some obscure
     nook.

   This file contains Unix-specific information. A lot of it. Unlike most
   other packages, C-Kermit tries very hard to be portable to every Unix
   variety (and every release of each one) known to exist, including many
   that are quite old, as well as to other platforms like VMS, AOS/VS,
   VOS, OS-9, the BeBox, the Amiga, etc.

   Since C-Kermit gets so deeply into the file system, i/o system, and
   other areas that differ radically from one Unix platform to the next,
   this means that a lot can go wrong when you try to install C-Kermit on
   (for example) a new release of a particular variety of Unix, in which
   certain things might have changed that C-Kermit depended upon.

   This file concentrates on installation. For a description of general
   configuration options for C-Kermit, please read the [36]Configurations
   Options document. For troubleshooting after installation, see the
   [37]General Hints and Tips and [38]Unix-Specific Hints and Tips
   documents. The latter, in particular, contains lots of information on
   lots of specific Unix platforms. If you want to work on the source
   code, see the [39]C-Kermit Program Logic Manual

   You may install C-Kermit:

     * From an "[40]install package", if one is available.
     * As a [41]prebuilt binary, if available, plus accompanying text
       files.
     * By building from [42]source code.

1. INTERNET QUICK START

   [ [43]Top ] [ [44]Contents ] [ [45]Next ] [ [46]Previous ]

   If your Unix computer is on the Internet and it has a C compiler,
   here's how to download, build, and install C-Kermit directly from the
   "tarballs" or Zip archives:

    1. Make a fresh directory and cd to it.
    2. Download the C-Kermit source code:
       [47]ftp://www.columbia.edu/kermit/archives/cku211.tar.Z (compress
       format) or [48]ftp://www.columbia.edu/kermit/archives/cku211.tar.gz
       (gunzip format). If those links don't work, FTP transfers are being
       blocked; try these HTTP links instead:
       [49]http://kermit.columbia.edu/ftp/archives/cku211.tar.Z (compress
       format) or
       [50]http://kermit.columbia.edu/ftp/archives/cku211.tar.gz (gunzip
       format).
    3. Uncompress the compressed tar file with "uncompress" or "gunzip",
       according to which type of compressed file you downloaded. (If you
       don't understand this, you could download a (much larger)
       uncompressed tar archive directly:
       [51]ftp://www.columbia.edu/kermit/archives/cku211.tar or
       [52]http://kermit.columbia.edu/ftp/archives/cku211.tar
    4. Now type "tar xvf cku211.tar" to unpack the individual files from
       the tar archive.
    5. Type "rm cku211.tar" to get rid of the tar archive, which is no
       longer needed.
    6. Read the comments at the top of the makefile to find out which
       target to use and then type the appropriate "make" command, such as
       "make linux", "make solaris8", etc.
    7. This produces a binary in your current directory called "wermit".
       Start it by typing "./wermit" and [53]try it out to make sure it
       works. Then read [54]Section 5 for how to install it, or simply
       copy the wermit binary to the desired public directory, rename it
       to kermit, and give it the needed permissions (and, if it is going
       to be used to dial out, give it the same group and owner and
       permissions as the cu, tip, or minicom program).

   For secure installations, see [55]Sections 5 and [56]16.

2. INSTALLING FROM PACKAGES

   [ [57]Top ] [ [58]Contents ] [ [59]Next ] [ [60]Previous ]

   Various Unix varieties -- Linux, Solaris, AIX, etc -- now incorporate
   the idea of "install packages", and many users expect to find all new
   applications in this format. A selection of install packages might be
   available for any given release of C-Kermit, but there is a tradeoff
   between convenience and safety. Unix presents several notable problems
   to the builder of install packages:

    a. Since C-Kermit is portable to many non-Unix platforms (VMS, VOS,
       AOS/VS, etc), some of the files in the C-Kermit distribution do not
       fit into the Unix application model. In particular, C-Kermit
       includes some plain text files (described in [61]Section 5) and
       Unix has no standard place to put such files. Typical Unix package
       managers do not allow for them. Where should they go, and how will
       the user know where to find them?
    b. Installation of any program that will be used to make modem calls
       requires some important decisions from the installer regarding
       security and privilege.

   Item (b) is discussed at length in [62]Sections 10 and [63]11 of this
   document, but the package-related aspects are also given here. The
   basic problem is that Unix dialout devices and the UUCP "lock files"
   that regulate contention for them (described in [64]Section 10) are
   usually protected against "world". Therefore, the install procedure
   must either run as root in order to give the Kermit binary the required
   permissions, group, and/or owner, or else the dialout devices and
   associated directories must be open for group or world reading and
   writing. Otherwise, the Kermit program just installed WILL NOT WORK for
   dialing out.

   Thus, a well-crafted installation procedure should present the options
   and allow the installer to choose the method, if any, for regulating
   access to the dialout devices:

    a. Check the permissions of the lockfile directory and the dialout
       devices. If they do not allow group or world R/W access, then:
    b. "Your UUCP lockfile directory and/or dialout devices require
       privilege to access. You must either change their permissions or
       install Kermit with privileges."
    c. "If you wish to install Kermit with privileges, it will be given
       the same owner, group, and permissions as the cu program so it can
       use the dialout devices." (This is increasingly problematic as some
       newer Unix systems like Mac OS X don't have a cu program, or even a
       serial port!)
    d. If they choose (c) but the user is not root, give a message that
       the install procedure can be run only by root and then quit.

   It should go without saying, of course, that any binaries that are to
   be included in an install package should be built fresh on the exact
   platform (e.g. Red Hat 8.0 on Intel) for which the package is targeted;
   prebuilt binaries ([65]next section) from other sites are likely to
   have library mismatches. [66]CLICK HERE for more about building
   C-Kermit install packages.

   The Kermit Project does not have the resources or the expertise to make
   install packages for every platform. Most install packages, therefore,
   are contributed by others, and they do not necessarily follow the
   guidelines given above. Pay attention to what they do.

   If you are an end user who has obtained a C-Kermit install package for
   a particular platform, you should be aware that some additional steps
   might needed if you want to use Kermit to dial out. Read [67]Section 10
   for details.

3. INSTALLING PREBUILT BINARIES

   [ [68]Top ] [ [69]Contents ] [ [70]Next ] [ [71]Previous ]

   Hundreds of prebuilt C-Kermit binaries are available on the CDROM in
   the BINARY tree [NOTE: The C-Kermit CDROM is still for version 7.0],
   and at our ftp site in the [72]kermit/bin area (with names starting
   with "ck"), also accessible on the [73]C-Kermit website. To install a
   prebuilt binary:

    a. Rename the binary to "wermit".
    b. Make sure it works; some tests are suggested in [74]Section 7.
    c. Follow steps (b) through (e) in [75]Section 4.
    d. Install related files as described in [76]Section 5.

   But first... Please heed the following cautions:

    a. If you pick the wrong binary, it won't work (or worse).
    b. Even when you pick the appropriate binary, it still might not work
       due to shared-library mismatches, etc. (see [77]Section 4.0).
    c. Don't expect a binary built on or for version n of your OS to work
       on version n - x (where x > 0). However, it is supposed to be safe
       to run a binary built on (or for) an older OS release on a newer
       one (but is [78]increasingly less so as time-honored principles of
       stability and backwards compatibility go fading into obscurity).

   Therefore, it is always better to build your own binary from source
   code ([79]next section) if you can. But since it is increasingly common
   for Unix systems (not to mention VMS and other OS's) to be delivered
   without C compilers, it is sometimes not possible. In such cases, try
   the most appropriate prebuilt binary or binaries, and if none of them
   work, [80]contact us and we'll see what we can do to help.

4. BUILDING FROM SOURCE CODE

   [ [81]Top ] [ [82]Contents ] [ [83]Next ] [ [84]Previous ]

   Also see: [85]Section 8 and [86]Section 9.

   C-Kermit is designed to be built and used on as many platforms as
   possible: Unix and non-Unix, old and new (and ancient), ANSI C and K&R.
   The Unix version does not use or depend on any external tools for
   building except the "make" utility, the C compiler, the linker, and the
   shell. It does not use any external automated configuration tools such
   as configure, autoconf, automake, libtool, etc. Everything in C-Kermit
   has been built by hand based on direct experience or reports or
   contributions from users of each platform.

   The [87]C-Kermit makefile contains the rules for building the program
   for each of the hundreds of different kinds of Unix systems that
   C-Kermit attempts to support. It covers all Unix variations since about
   1980 -- pretty much everything after Unix V6. Separate makefiles are
   used for [88]Plan 9 and [89]2.x BSD.

   Prerequisites:

     * The C compiler, linker, and make program must be installed.
     * The C libraries and header files must be installed (*).
     * The C-Kermit source code and makefile in your current directory.
     * The C-Kermit text files ([90]Section 5) in your current directory.

     * This is becoming problematic in this new age of "selective
       installs" e.g. of Linux packages. C-Kermit builds will often fail
       because replying "no" to some obscure Linux installation option
       will result in missing libraries or header files. Ditto on
       platforms like AIX and Solaris that don't come with C compilers,
       and then later have gcc installed, but are still missing crucial
       libraries, like libm (math).

   Plus:

     * For TCP/IP networking support, the sockets library and related
       header files must be installed.
     * The math library for floating-point arithmetic support (can be
       deselected by adding -DNOFLOAT to CFLAGS and removing -lm from
       LIBS).
     * Many and varied security libraries for building a secure version
       (Kerberos, SSL/TLS, SRP, Zlib,...) These are required only if you
       select a secure target.
     * For the curses-based fullscreen file-ransfer display, the curses or
       ncurses header file(s) and library, and probably also the termcap
       and/or termlib library. Note that the names and locations of these
       files and libraries are likely to change capriciously with every
       new release of your Unix product. If you discover that the C-Kermit
       build procedure fails because your curses and/or termxxx headers or
       libraries are not named or located as expected, please [91]let us
       know. In the meantime, work around by installing symlinks.
     * IMPORTANT: Modern Linux distributions might give you the choice
       during installation of whether to install the "ncurses development
       package" (perhaps called "ncurses-devel"). If you did not install
       it, you won't be able to build C-Kermit with curses support
       included. In this case, either go back and install ncurses, or else
       choose (or create) a non-curses makefile target for your platform.
       To install the ncurses developers tools in Red Hat Linux, do
       "apt-get install ncurses-developer" or if you have the CD:

mount redhat cdrom
goto RedHat/RPMS
rpm -ivh ncurses-devel*.rpm
or to have the exact name ls ncurse* and load as
rpm -ivh filename
then leave the cdrom and unmount it.

     * In AIX you might have to go back and install any or all of:

bos.adt.base
bos.adt.include
bos.adt.lib
bos.adt.libm
bos.adt.utils

       from the first installation CD.

   Depending on where you got it, the makefile might need to be renamed
   from ckuker.mak to makefile. Directions:

    a. Type "make xxx" where xxx is the name of the makefile target most
       appropriate to your platform, e.g. "make linux", "make aix43", etc.
       Read the [92]comments at the top of the makefile for a complete
       list of available targets (it's a long list).
    b. Test the resulting 'wermit' file (see [93]Section 7 for
       suggestions). If it's OK, proceed; otherwise [94]notify us.

     NOTE: steps (c) through (e) can be accomplished using the
     [95]makefile 'install' target as described in [96]Section 5.4.
    c. Rename the 'wermit' file to 'kermit', copy it to the desired binary
       directory (such as /usr/local/bin or /opt/something), and if it is
       to be used for dialing out, give it the same owner, group, and
       permissions as the 'cu' program (IMPORTANT: read [97]Sections 10
       and [98]11 for details).
    d. Install the man page, ckuker.nr, with your other man pages.
    e. Install the accompanying text files (see [99]Section 5).
    f. If you want C-Kermit to also offer a Telnet command-line
       personality, make a symbolic link as follows:

cd directory-where-kermit-binary-is
ln -s kermit telnet

       If you want C-Kermit to be the default Telnet client, make sure the
       directory in which you created the symlink is in the PATH ahead of
       the where the regular Telnet client is.
    g. If you want C-Kermit to also offer an FTP command-line personality,
       make a symlink called "ftp" as in (f).
    h. If you want C-Kermit to also offer an FTTP command-line
       personality, make a symlink called "http" as in (f).
    i. If you want to offer an Internet Kermit Service, follow the
       directions in the [100]IKSD Administrator's Guide.

4.0. Special Considerations for C-Kermit 8.0-9.0

   [ [101]Top ] [ [102]Contents ] [ [103]Next ]

   Also see: [104]C-Kermit Configuration Options

   SECTION CONTENTS

4.1. [105]The Unix Makefile
4.2. [106]The C-Kermit Initialization File
4.3. [107]The 2.x BSD Makefile
4.4. [108]The Plan 9 Makefile
4.5. [109]Makefile Failures

   (Also see the [110]Configurations Options document, [111]Section 8).

   Lots of new features have been added in versions 7.0 and 8.0 that
   require access to new symbols, APIs, libraries, etc, and this will no
   doubt cause problems in compiling, linking, or execution on platforms
   where 6.0 and earlier built without incident. This section contains
   what we know as of the date of this file.

   The first category concerns the new Kermit Service Daemon (IKSD; see
   the [112]IKSD Administrator's Guide for details):

   The wtmp File
          When C-Kermit is started as an IKSD (under inetd), it makes
          syslog and wtmp entries, and also keeps its own ftpd-like log.
          The code assumes the wtmp log is /var/log/wtmp on Linux and
          /usr/adm/wtmp elsewhere. No doubt this assumption will need
          adjustment. Use -DWTMPFILE=path to override at compile time
          (there is also a runtime override). See [113]iksd.html for
          details.

   UTMP, utsname(), etc
          C-Kermit 7.0 gets as much info as it can about its job -- mainly
          for IKSD logging -- from utmp. But of course utmp formats and
          fields differ, and for that matter, there can be two different
          header files, <utmp.h> and <utmpx.h>. Look for HAVEUTMPX and
          HAVEUTHOST in [114]ckufio.c and let me know of any needed
          adjustments.

   Password lookup
          IKSD needs to authenticate incoming users against the password
          list. In some cases, this requires the addition of -lcrypt (e.g.
          in Unixware 2.x). In most others, the crypt functions are in the
          regular C library. If you get "crypt" as an unresolved symbol at
          link time, add -lcrypt to LIBS. If your site has local
          replacement libraries for authentication, you might need a
          special LIBS clause such as "LIBS=-L/usr/local/lib -lpwent".

          These days most Unix systems take advantage of shadow password
          files or Pluggable Authentication Modules (PAM). If your system
          uses shadow passwords you must add -DCK_SHADOW to the CFLAGS
          list. If your system requires PAM you must add -DCK_PAM to the
          CFLAGS and -lpam -ldl to LIBS.

   getusershell()
          This is called by the IKSD at login time to see if a user has
          been "turned off". But many Unix platforms lack this function.
          In that case, you will get unresolved symbol reports at link
          time for _getusershell, _endusershell; to work around, add
          -DNOGETUSERSHELL.

   initgroups()
          This is called by IKSD after successful authentication. But some
          platforms do not have this function, so obviously it can't be
          called there, in which case add -DNOINITGROUPS.

   setreuid(), setreuid(), setregid() not found or "deprecated"
          Find out what your Unix variety wants you to use instead, and
          make appropriate substitutions in routine zvpass(), module
          [115]ckufio.c, and [116]let us know.

   printf()
          IKSD installs a printf() substitute to allow redirection of
          printf-like output to the connection. However, this can conflict
          with some curses libraries. In this case, separate binaries must
          be built for IKSD and non-IKSD use.

   If you encounter difficulties with any of the above, and you are not
   interested in running C-Kermit as an IKSD, then simply add NOIKSD to
   CFLAGS and rebuild. Example:

make sco286
(get lots of errors)
make clean
make sco286 "KFLAGS=-DNOIKSD"

   Some non-IKSD things to watch out for:

   Return type of main()
          The main() routine is in [117]ckcmai.c. If you get complaints
          about "main: return type is not blah", define MAINTYPE on the CC
          command line, e.g.:

make xxx "KFLAGS=-DMAINTYPE=blah

          (where blah is int, long, or whatever). If the complaint is
          "Attempt to return a value from a function of type void" then
          add -DMAINISVOID:

make xxx "KFLAGS=-DMAINISVOID=blah

   DNS Service Records
          This feature allows a remote host to redirect C-Kermit to the
          appropriate socket for the requested service; e.g. if C-Kermit
          requests service "telnet" and the host offers Telnet service on
          port 999 rather than the customary port 23. If you get
          compile-time complaints about not being able to find <resolv.h>,
          <netdb.h>, or <arpa/nameser.h>, add -DNO_DNS_SRV to CFLAGS. If
          you get link-time complaints about unresolved symbols res_search
          or dn_expand, try adding -lresolve to LIBS.

   \v(ipaddress)
          If "echo \v(ipaddress)" shows an empty string rather than your
          local IP address, add -DCKGHNLHOST to CFLAGS and rebuild.

   <sys/wait.h>
          If this file can't be found at compile time, add -DNOREDIRECT to
          CFLAGS. This disables the REDIRECT and PIPE commands and
          anything else that needs the wait() system service.

   syslog()
          C-Kermit can now write syslog records. Some older platforms
          might not have the syslog facility. In that case, add
          -DNOSYSLOG. Others might have it, but require addition of
          -lsocket to LIBS (SCO OSR5 is an example). See [118]Section 15.

   putenv()
          If "_putenv" comes up as an undefined symbol, add -DNOPUTENV to
          CFLAGS and rebuild.

   "Passing arg1 of 'time' from incompatible pointer"
          This is a mess. See the mass of #ifdefs in the appropriate
          module, [119]ckutio.c or [120]ckufio.c.

   gettimeofday()
          Wrong number of arguments. On most platforms, gettimeofday()
          takes two arguments, but on a handful of others (e.g. Motorola
          System V/88 V4, SNI Reliant UNIX 5.43, etc) it takes one. If
          your version of gettimeofday() is being called with two args but
          wants one, add -DGTODONEARG.

   "Assignment makes pointer from integer without a cast"
          This warning might appear in [121]ckutio.c or [122]ckufio.c. (or
          elsewhere), and usually can be traced to the use of a system or
          library function that returns a pointer but that is not declared
          in the system header files even though it should be. Several
          functions are commonly associated with this error:

          + getcwd(): Add -DDCLGETCWD to CFLAGS and rebuild.
          + popen() : Add -DDCLPOPEN to CFLAGS and rebuild.
          + fdopen(): Add -DDCLFDOPEN to CFLAGS and rebuild.

   "Operands of = have incompatible types"
   "Incompatible types in assignment"
          If this comes from [123]ckcnet.c and comes from a statement
          involving inet_addr(), try adding -DINADDRX to CFLAGS. If that
          doesn't help, then try adding -DNOMHHOST.

   Complaints about args to get/setsockopt(), getpeername(), getsockname()
          These are all in [124]ckcnet.c. Different platforms and OS's and
          versions of the same OS change this all the time: int, size_t,
          unsigned long, etc. All the affected variables are declared
          according to #ifdefs within ckcnet.c, so find the declarations
          and adjust the #ifdefs accordingly.

   size_t
          In case of complaints about "unknown type size_t", add
          -DSIZE_T=int (or other appropriate type) to CFLAGS.

   'tz' undefined
   Use of undefined enum/struct/union 'timezone'
          Left of 'tv_sec' specifies undefined struct/union 'timeval' And
          similar complaints in [125]ckutio.c: Add -DNOGFTIMER and/or
          -DNOTIMEVAL.

   Symlinks
          The new built-in DIRECTORY command should show symlinks like "ls
          -l" does. If it does not, check to see if your platform has the
          lstat() and readlink() functions. If so, add -DUSE_LSTAT and
          -DCKSYMLINK to CFLAGS and rebuild. On the other hand, if lstat()
          is unresolved at link time, add -DNOLSTAT to CFLAGS. If
          readlink() is also unresolved, add -DNOSYMLINK.

   realpath()
          Link-time complains about realpath() -- find the library in
          which it resides and add it to LIBS (example for Unixware 7.1:
          "-lcudk70") or add -DNOREALPATH to CFLAGS and rebuild. If built
          with realpath() but debug log file is truncated or mangled,
          ditto (some realpath() implementations behave differently from
          others). If built with realpath() and seemingly random core
          dumps occur during file path resolution, ditto.

   Failure to locate header file <term.h>
          Usually happens on Linux systems that have the C compiler
          installed, but not the ncurses package (see comments about
          selective installs above). Go back and install ncurses, or use
          "make linuxnc" (Linux No Curses).

   "Can't find shared library libc.so.2.1"
   "Can't find shared library libncurses.so.3.0", etc...
          You are trying to run a binary that was built on a computer that
          has different library versions than your computer, and your
          computer's loader is picky about library version numbers.
          Rebuild from source on your computer.

   Time (struct tm) related difficulties:
          Errors like the following:

"ckutio.c", line 11994: incomplete struct/union/enum tm: _tm
"ckutio.c", line 11995: error: cannot dereference non-pointer type
"ckutio.c", line 11995: error: assignment type mismatch
"ckutio.c", line 11997: warning: using out of scope declaration: localtime
"ckutio.c", line 11997: error: unknown operand size: op "="
"ckutio.c", line 11997: error: assignment type mismatch
"ckutio.c", line 11998: error: undefined struct/union member: tm_year
"ckutio.c", line 12000: error: undefined struct/union member: tm_mon
"ckutio.c", line 12001: error: undefined struct/union member: tm_mday
"ckutio.c", line 12002: error: undefined struct/union member: tm_hour
"ckutio.c", line 12003: error: undefined struct/union member: tm_min
"ckutio.c", line 12004: error: undefined struct/union member: tm_sec

          are due to failure to include the appropriate time.h header
          files. Unix platforms generally have one or more of the
          following: <time.h>, <sys/time.h>, and <sys/timeb.h>. Any
          combination of these might be required. Defaults are set up for
          each makefile target. The defaults can be corrected on the CC
          command line by adding the appropriate definition from the
          following list to CFLAGS:

-DTIMEH         Include <time.h>
-DNOTIMEH       Don't include <time.h>
-DSYSTIMEH      Include <sys/time.h>
-DNOSYSTIMEH    Don't include <sys/time.h>
-DSYSTIMEBH     Include <sys/timeb.h>
-DNOSYSTIMEBH   Don't include <sys/timeb.h>

          Note that <sys/timeb.h> is relatively scarce in the System V and
          POSIX environments; the only platform of recent vintage where it
          was/is used is OSF/1 and its derivatives (Digital Unix and Tru64
          Unix).

   Struct timeval and/or timezone not declared:
          In some cases, merely including the appropriate time.h header
          files is still not enough. POSIX.1 does not define the timeval
          struct, and so the items we need from the header are protected
          against us by #ifndef _POSIX_SOURCE or somesuch. In this case,
          we have to declare the timeval (and timezone) structs ourselves.
          To force this, include -DDCLTIMEVAL in CFLAGS.

   Warnings about dn_expand() Argument #4
          WARNING: argument is incompatible with prototyp. It's the old
          char versus unsigned char stupidity again. Try to find a
          compiler switch like GCC's "-funsigned-char". Failing that, add
          -DCKQUERYTYPE=xxx to CFLAGS, where xxx is whatever 'man
          dn_expand' tells you the type of the 4th argument should be
          (presumably either char or unsigned char; in the latter case use
          CHAR to avoid confusion caused by multiple words.

   Switch Table Overflow (in [126]ckcuni.c)
          Add -DNOUNICODE to CFLAGS.

   Compile-time warnings about ck_out() or tgetstr() or tputs():
          Easy solution: Add -DNOTERMCAP to CFLAGS. But then you lose the
          SCREEN function. Real solution: Try all different combinations
          of the following CFLAGS:

-DTPUTSARGTYPE=char    -DTPUTSFNTYPE=int
-DTPUTSARGTYPE=int     -DTPUTSFNTYPE=void

          Until the warnings go away, except maybe "ck_outc: return with a
          value in a function returning void", and in that case also add
          -DTPUTSISVOID.

   "Passing arg 1 of to tputs() makes pointer from integer without a
          cast":
          Add -DTPUTSARG1CONST to CFLAGS.

   "Undefined symbol: dup2"
          Add -DNOZEXEC to CFLAGS.

   "header file 'termcap.h' not found"
          Add -DNOHTERMCAP to CFLAGS.

   Other difficulties are generally of the "where is curses.h and what is
   it called this week?" variety (most easily solved by making symlinks in
   the include and lib directories), or overzealous complaints regarding
   type mismatches in function calls because of the totally needless and
   silly signed versus unsigned char conflict (*), etc. In any case,
   please send any compilation or linking warnings or errors to the
   author, preferably along with fixes.

     * C-Kermit does not use the signed property of chars at all anywhere,
       ever. So if all chars and char *'s can be made unsigned at compile
       time, as they can in gcc with "-funsigned-char", they should be.

   IMPORTANT: If you find any of these hints necessary for a particular
   make target (or you hit upon others not listed here), PLEASE SEND A
   REPORT TO:

[127]kermit-support@columbia.edu

4.1. The Unix Makefile

   [ [128]Top ] [ [129]Contents ] [ [130]Section Contents ] [ [131]Next ]
   [ [132]Previous ]

   If your distribution does not contain a file with the name "makefile"
   or "Makefile", then rename the file called ckuker.mak to makefile:

mv ckuker.mak makefile

   Then type "make xxx", where xxx is the platform you want to build
   C-Kermit for. These are listed in the [133]comments at the top of the
   makefile. For example, to build C-Kermit for Linux, type:

make linux

   Here are some typical examples:

     Target    Description
     linux     Linux, any version on any hardware platform
     openbsd   OpenBSD, any version on any hardware platform
     aix43     AIX 4.3
     aix43g    AIX 4.3, built with gcc
     solaris9  Solaris 9
     solaris9g Solaris 9 built with gcc
     hpux1100  HP-UX 11-point-anything

   The makefile is quite long, and at least two versions of Unix, SCO
   Xenix/286 and 2.x BSD, cannot cope with its length. An attempt to "make
   sco286" gives the message "Make: Cannot alloc mem for env.. Stop".
   Solution: edit away some or all of the nonrelevant material from the
   makefile. (A separate version of the makefile is provided for BSD 2.x:
   ckubs2.mak but C-Kermit 8.0 can't be built for BSD 2.x -- it has simply
   grown too large.)

   Some make programs reportedly cannot handle continued lines (lines
   ending in backslash (\)). If you have a problem with the makefile, try
   editing the makefile to join the continued lines (remove the
   backslashes and the following linefeed).

   Other makefile troubles may occur because tabs in the makefile have
   somehow been converted to spaces. Spaces and tabs are distinct in Unix
   makefiles.

   Similarly, carriage returns might have been added to the end of each
   line, which also proves confusing to most Unix versions of make.

   Check to see if there are comments about your particular version in its
   makefile target itself. In a text editor such as EMACS or VI, search
   for the make entry name followed by a colon, e.g. "linux:" (if you
   really are building C-Kermit for Linux, do this now).

   Check to see if there are comments about your particular version in the
   [134]ckubwr.txt file ([135]CLICK HERE for the Web version).

   If you have trouble with building [136]ckwart.c, or running the
   resulting wart preprocessor program on [137]ckcpro.w:

    1. Just "touch" the [138]ckcpro.c file that comes in the distribution
       and then give the "make" command again, or:
    2. Compile ckwart.c "by hand": cc -o wart ckwart.c, or:
    3. Try various other tricks. E.g. one Linux user reported that that
       adding the "static" switch to the rule for building wart fixed
       everything:

wart: ckwart.$(EXT)
        $(CC) -static -o wart ckwart.$(EXT) $(LIBS)

   If your compiler supports a compile-time option to treat ALL chars (and
   char *'s, etc) as unsigned, by all means use it -- and send me email to
   let me know what it is (I already know about gcc -funsigned-char).

   To add compilation options (which are explained later in this document)
   to your makefile target without editing the makefile, include
   "KFLAGS=..." on the make command line, for example:

make linux KFLAGS=-DNODEBUG
make bsd "KFLAGS=-DKANJI -DNODEBUG -DNOTLOG -DDYNAMIC -UTCPSOCKET"

   Multiple options must be separated by spaces. Quotes are necessary if
   the KFLAGS= clause includes spaces. The KFLAGS are added to the end of
   the CFLAGS that are defined in the selected makefile target. For
   example, the "bsd" entry includes -DBSD4 -DTCPSOCKET, so the second
   example above compiles Kermit with the following options:

-DBSD4 -DTCPSOCKET -DKANJI -DNODEBUG -DNOTLOG -DDYNAMIC -UTCPSOCKET

   (Notice how "-UTCPSOCKET" is used to negate the effect of the
   "-DTCPSOCKET" option that is included in the makefile target.)

   WARNING: Be careful with KFLAGS. If you build C-Kermit, change some
   files, and then run make again using the same make entry but specifying
   different KFLAGS than last time, make won't detect it and you could
   easily wind up with inconsistent object modules, e.g. some of them
   built with a certain option, others not. When in doubt, "make clean"
   first to make sure all your object files are consistent. Similarly, if
   you change CFLAGS, LIBS, or any other items in the makefile, or you
   rebuild using a different makefile target, "make clean" first.

   If you create a new makefile target, use static linking if possible.
   Even though this makes your C-Kermit binary bigger, the resulting
   binary will be more portable. Dynamically linked binaries tend to run
   only on the exact configuration and version where they were built; on
   others, invocation tends to fail with a message like:

Can't find shared library "libc.so.2.1"

4.2. The C-Kermit Initialization File

   [ [139]Top ] [ [140]Contents ] [ [141]Section Contents ] [ [142]Next ]
   [ [143]Previous ]

   (This section is obsolete.) Read [144]Section 5 about the
   initialization file.

4.3. The 2.x BSD Makefile

   [ [145]Top ] [ [146]Contents ] [ [147]Section Contents ] [ [148]Next ]
   [ [149]Previous ]

     This section is obsolete. C-Kermit 6.0 was the last release that
     could be built on PDP-11 based BSD versions.

4.4. The Plan 9 Makefile

   [ [150]Top ] [ [151]Contents ] [ [152]Section Contents ] [ [153]Next ]
   [ [154]Previous ]

   Use the separate makefile [155]ckpker.mk. NOTE: The Plan 9 version of
   C-Kermit 8.0 has not yet been built. There should be no impediment to
   building it. However, even when built successfully, certain key
   features are missing, notably TCP/IP networking.

4.5. Makefile Failures

   [ [156]Top ] [ [157]Contents ] [ [158]Section Contents ] [
   [159]Previous ]

   First, be sure the source files are stored on your current disk and
   directory with the right names (in lowercase). Second, make sure that
   the makefile itself does not contain any lines with leading spaces:
   indented lines must all start with horizontal TAB, and no spaces.

   Then make sure that your Unix PATH is defined to find the appropriate
   compiler for your makefile target. For example, on SunOS systems, "make
   sunos41" builds C-Kermit for the BSD environment, and assumes that
   /usr/ucb/cc will be used for compilation and linking. If your PATH has
   /usr/5bin ahead of /usr/ucb, you can have problems at compile or link
   time (a commonly reported symptom is the inability to find "ftime"
   during linking). Fix such problems by redefining your Unix PATH, or by
   specifying the appropriate "cc" in CC= and CC2= statements in your
   makefile target.

   During edits 166-167, considerable effort went into making C-Kermit
   compilable by ANSI C compilers. This includes prototyping all of
   C-Kermit's functions, and including the ANSI-defined system header
   files for system and library functions, as defined in K&R, second
   edition: <string.h>, <stdlib.h>, <unistd.h> (except in NeXTSTEP this is
   <libc.h>), and <sys/stdtypes.h>. If you get warnings about any of these
   header files not being found, or about argument mismatches involving
   pid_t, uid_t, or gid_t, look in ckcdeb.h and make amendments. C-Kermit
   assumes it is being compiled by an ANSI-compliant C compiler if
   __STDC__ is defined, normally defined by the compiler itself. You can
   force ANSI compilation without defining __STDC__ (which some compilers
   won't let you define) by including -DCK_ANSIC on the cc command line.

   On the other hand, if your compiler defines __STDC__ but still
   complains about the syntax of Kermit's function prototypes, you can
   disable the ANSI-style function prototyping by including -DNOANSI on
   the command line.

   For SCO OpenServer, UNIX, ODT, and XENIX compilations, be sure to pick
   the most appropriate [160]makefile target, and be sure you have
   installed an SCO development system that is keyed to your exact SCO
   operating system release, down to the minor version (like 2.3.1).

   Also note that SCO distributes some of its libraries in encrypted form,
   and they must be decrypted before C-Kermit can be linked with them. If
   not, you might see a message like:

ld: file /usr/lib/libsocket.a is of unknown type: magic number = 6365

   To decrypt, you must supply a key (password) that came with your
   license. Call SCO for further info.

   If your compiler uses something other than int for the pid (process id)
   data type, put -DPID_T=pid_t or whatever in your CFLAGS.

   If you get complaints about unknown data types uid_t and gid_t, put
   -DUID_T=xxx -DGID_T=yyy in your CFLAGS, where xxx and yyy are the
   appropriate types.

   If your compilation fails because of conflicting or duplicate
   declarations for sys_errlist, add -DUSE_STRERROR or -DNDSYSERRLIST to
   CFLAGS.

   If your compilation dies because getpwnam() is being redeclared (or
   because of "conflicting types for getwpnam"), add -DNDGPWNAM to your
   CFLAGS. If that doesn't work, then add -DDCGPWNAM to your CFLAGS (see
   ckufio.c around line 440).

   If the compiler complains about the declaration of getpwnam() during an
   ANSI C compilation, remove the declaration from ckufio.c or change the
   argument in the prototype from (char *) to (const char *).

   If you get complaints that getpwuid() is being called with an improper
   type, put -DPWID_T=xx in your CFLAGS.

   If you get compile-time warnings that t_brkc or t_eofc (tchars
   structure members, used in BSD-based versions) are undefined, or
   structure-member- related warnings that might be traced to this fact,
   add -DNOBRKC to CFLAGS.

   If you get a linker message to the effect that _setreuid or _setregid
   is not defined, add -DNOSETREU to CFLAGS, or add -DCKTYP_H=blah to
   CFLAGS to make C-Kermit read the right <types.h>-kind-of-file to pick
   up these definitions.

   If you get a message that _popen is undefined, add -DNOPOPEN to CFLAGS.

   If you get a complaint at compile time about an illegal pointer-integer
   combination in ckufio.c involving popen(), or at link time that _popen
   is an undefined symbol, add the declaration "FILE *popen();" to the
   function zxcmd() in ckufio.c (this declaration is supposed to be in
   <stdio.h>). If making this change does not help, then apparently your
   Unix does not have the popen() function, so you should add -DNOPOPEN to
   your make entry, in which case certain functions involving "file" i/o
   to the standard input and output of subprocesses will not be available.

   If your linker complains that _getcwd is undefined, you can add a
   getcwd() function to ckufio.c, or add it to your libc.a library using
   ar:

#include <stdio.h>

char *
getcwd(buf,size) char *buf; int size; {
#ifndef NOPOPEN
#ifdef DCLPOPEN
    FILE *popen();
#endif
    FILE *pfp;

    if (!buf) return(NULL);
    if (!(pfp = popen("pwd","r"))) return(NULL);
    fgets(buf,size-2,pfp);
    pclose(pfp);
    buf[strlen(buf)-1] = '\0';
    return((char *)buf);
#else
    buf[0] = '\0';
    return(NULL);
#endif /* NOPOPEN */
}

#ifdef NOPOPEN
FILE *popen(s,t) char *s,*t; {
    return(NULL);
}
#endif /* NOPOPEN */

   If you get complaints about NPROC having an invalid value, add a valid
   definition for it (depends on your system), as in the cray entry.

   If you get some symbol that's multiply defined, it probably means that
   a variable name used by Kermit is also used in one of your system
   libraries that Kermit is linked with. For example, under PC/IX some
   library has a variable or function called "data", and the variable
   "data" is also used extensively by Kermit. Rather than edit the Kermit
   source files, just put a -D in the make entry CFLAGS to change the
   Kermit symbol at compile time. In this example, it might be
   -Ddata=xdata.

   Some symbol is defined in your system's header files, but it produces
   conflicts with, or undesired results from, Kermit. Try undefining the
   symbol in the makefile target's CFLAGS, for example -UFIONREAD.

   Some well-known symbol is missing from your system header files. Try
   defining in the makefile target's CFLAGS, for example -DFREAD=1.

   You get many warnings about pointer mismatches. This probably means
   that Kermit is assuming an int type for signal() when it should be
   void, or vice-versa. Try adding -DSIG_I (for integer signal()) or
   -DSIG_V (for void) to CFLAGS. Or just include KFLAGS=-DSIG_V (or
   whatever) in your "make" command, for example:

make bsd KFLAGS=-DSIG_V

   You get many messages about variables that are declared and/or set but
   never used. It is difficult to avoid these because of all the
   conditional compilation in the program. Ignore these messages.

   Some of C-Kermit's modules are so large, or contain so many character
   string constants, or are so offensive in some other way, that some C
   compilers give up and refuse to compile them. This is usually because
   the -O (optimize) option is included in the make entry. If this happens
   to you, you can (a) remove the -O option from the make entry, which
   will turn off the optimizer for ALL modules; or (b) compile the
   offending module(s) by hand, including all the switches from make entry
   except for -O, and then give the appropriate "make" command again; or
   (c) increase the value of the -Olimit option, if your compiler supports
   this option; or (d) change the [161]makefile target to first compile
   each offending module explicitly without optimization, then compile the
   others normally (with optimization), for example:

#Fortune 32:16, For:Pro 2.1 (mostly like 4.1bsd)
ft21:
        @echo 'Making C-Kermit $(CKVER) for Fortune 32:16 For:Pro 2.1...'
        $(MAKE) ckuusx.$(EXT) "CFLAGS= -DNODEBUG -DBSD4 -DFT21 -DNOFILEH \
        -SYM 800 \ -DDYNAMIC -DNOSETBUF -DCK_CURSES $(KFLAGS) -DPID_T=short"
        $(MAKE) ckuxla.$(EXT) "CFLAGS= -DNODEBUG -DBSD4 -DFT21 -DNOFILEH \
        -SYM 800 \ -DDYNAMIC -DNOSETBUF -DCK_CURSES $(KFLAGS) -DPID_T=short"
        $(MAKE) ckudia.$(EXT) "CFLAGS= -DNODEBUG -DBSD4 -DFT21 -DNOFILEH \
        -SYM 800 \ -DDYNAMIC -DNOSETBUF -DCK_CURSES $(KFLAGS) -DPID_T=short"
        $(MAKE) wermit "CFLAGS= -O -DNODEBUG -DBSD4 -DFT21 -DNOFILEH -SYM 800 \
        -DDYNAMIC -DNOSETBUF -DCK_CURSES $(KFLAGS) -DPID_T=short" \
        "LNKFLAGS= -n -s" "LIBS= -lcurses -ltermcap -lv -lnet"

   As an extreme example, some compilers (e.g. gcc on the DG AViiON) have
   been known to dump core when trying to compile ckwart.c with
   optimization. So just do this one "by hand":

cc -o wart ckwart.c

   or:

touch ckcpro.c

   and then give the "make" command again.

   Speaking of wart, it is unavoidable that some picky compilers might
   generate "statement unreachable" messages when compiling ckcpro.c.
   Unreachable statements can be generated by the wart program, which
   generates ckcpro.c automatically from [162]ckcpro.w, which translates
   lex-like state/input constructions into a big switch/case construction.

   Some function in Kermit wreaks havoc when it is called. Change all
   invocations of the function into a macro that evaluates to the
   appropriate return code that would have been returned by the function
   had it been called and failed, for example: -Dzkself()=0. Obviously not
   a good idea if the function is really needed.

   If you have just installed SunOS 4.1.2 or 4.1.3, you might find that
   C-Kermit (and any other C program) fails to link because of unresolved
   references from within libc. This is because of a mistake in Sun's
   /usr/lib/shlib.etc files for building the new libc. Change the libc
   Makefile so that the "ld" lines have "-ldl" at the end. Change the
   README file to say "mv xccs.multibyte. xccs.multibyte.o" and follow
   that instruction.

5. INSTALLING THE KERMIT FILES

   [ [163]Top ] [ [164]Contents ] [ [165]Next ] [ [166]Previous ]

   SECTION CONTENTS

5.1. [167]The C-Kermit Initialization File
5.2. [168]Text Files
5.3. [169]Installing the Kermit Files
5.4. [170]The Makefile Install Target

   The C-Kermit executable does not need any external files to run.
   Unlike, say, the cu program, which on most platforms is useless unless
   you (as root) edit the /usr/spool/uucp/Systems and
   /usr/spool/uucp/Devices files to supply whatever obscure and
   undocumented syntax is required to match some supposedly user-friendly
   mnemonic to the real pathname of whatever device you want to use,
   Kermit runs on its own without needing any external configuration
   files, and lets you refer to device (and network hosts and services) by
   their own natural undisguised names.

   Nevertheless, a number of external files can be installed along with
   the C-Kermit executable if you wish. These include configuration and
   customization files that are read by Kermit as well as documentation
   files to be read by people. All of this material is (a) optional, and
   (b) available on the Kermit website:

[171]http://www.columbia.edu/kermit/

   and usually in a more pleasant form, perhaps also with updated content.
   So if your computer is on the Internet, there is no need to install
   anything but the Kermit executable if users know how to find the Kermit
   website (and if they don't, Kermit's "help" command tells them).

5.1. The C-Kermit Initialization File

   In C-Kermit 7.0 and earlier, the standard initialization file was a key
   C-Kermit component because:

    a. It "loaded" the dialing and network directories.
    b. It defined all the macros and variables for the services directory.
    c. It defined macros for quickly changing Kermit's file-transfer
       performance tuning.

   The standard initialization file is quite long (more than 600 lines)
   and requires noticeable processing time (the slower the computer, the
   more noticeable), yet few people actually use the services directory,
   whose definition takes up most of its bulk. Meanwhile, in C-Kermit 8.0,
   many of the remaining functions of the standard initialization file are
   now built in; for example, the FAST, CAUTIOUS, and ROBUST commands.

   More to the point, many of the settings that could be made only in the
   initialization and customization files can now be picked up from
   environment variables. The first group identifies initialization and
   directory files:

   CKERMIT_INI
          The path of your Kermit initialization file, if any. This
          overrides the built-in search for $HOME/.kermrc.

   K_CHARSET
          The character set used for encoding local text files. Equivalent
          to SET FILE CHARACTER-SET.

   K_DIAL_DIRECTORY
          The full pathname of one or more Kermit dialing directory files.
          Equivalent to SET DIAL DIRECTORY.

   K_NET_DIRECTORY
          The full pathname of one or more Kermit network directory files.
          Equivalent to SET NETWORK DIRECTORY.

   K_INFO_DIRECTORY
   K_INFO_DIR
          The full pathname of a directory containing Kermit (if any)
          containing ckubwr.txt and other Kermit text files. Overrides
          Kermit's built-in search for this directory.

   The next group is related to dialing modems:

   K_COUNTRYCODE
          The telephonic numeric country code for this location, e.g. 1
          for North America or 39 for Italy. It is recommended that this
          one be set for all users, system-wide. Not only is it used to
          process portable-format dialing directory entries, but it is
          also compared against Kermit's built-in list of "tone countries"
          to see if tone dialing can be used. Equivalent to Kermit's SET
          DIAL COUNTRY-CODE command.

   K_AREACODE
          The telephonic numeric area code for this location, e.g. 212 for
          Manhattan, New York, USA. Recommend this one also be set
          system-wide, so shared portable-format dialing directories will
          work automatically for everybody. Equivalent to Kermit's SET
          DIAL AREA-CODE command.

   K_DIAL_METHOD
          TONE or PULSE. Equivalent to Kermit's SET DIAL METHOD command.
          If a dial method is not set explicitly (or implicitly from the
          country code), Kermit does not specify a dialing method, and
          uses the modem's default method, which tends to be pulse.

   K_INTL_PREFIX
          The telephonic numeric international dialing prefix for this
          location. Equivalent to Kermit's SET DIAL INTL-PREFIX command.

   K_LD_PREFIX
          The telephonic numeric long-distance dialing prefix for this
          location. Equivalent to Kermit's SET DIAL LD-PREFIX command.

   K_PBX_ICP
          The telephonic numeric PBX internal call prefix for this
          location. Equivalent to Kermit's SET DIAL PBX-INSIDE-PREFIX
          command.

   K_PBX_OCP
          The telephonic numeric PBX external call prefix for this
          location. Equivalent to Kermit's SET DIAL PBX-OUTSIDE-PREFIX
          command.

   K_PBX_XCH
          The telephonic numeric PBX exchange (first part of the
          subscriber number). Equivalent to Kermit's SET DIAL PBX-EXCHANGE
          command.

   K_TF_AREACODE
          A list of one or more telephonic numeric toll-free area codes.

   K_TF_PREFIX
          The telephonic numeric toll-free dialing prefix, in case it is
          different from the long-distance prefix. Equivalent to Kermit's
          SET DIAL TF-PREFIX command.

   The final group includes well-known environment variables that are also
   used by Kermit:

   CDPATH
          Where the CD command should look for relative directory names.

   SHELL
          The path of your Unix shell. Used by the RUN (!) command to
          choose the shell to execute its arguments.

   USER
          Your Unix username.

   EDITOR
          The name or path of your preferred editor (used by the EDIT
          command). Equivalent to SET EDITOR.

   BROWSER
          The name or path of your preferred web browser (used by the
          BROWSE command). Equivalent to Kermit's SET BROWSER command.

   Does this mean the initialization file can be abolished? I think so.
   Here's why:

     * Kermit already does everything most people want it to do without
       one.
     * Important site-specific customizations can be done with global
       environment variables.
     * There is no longer any need for everybody to have to use the
       standard initialization file.
     * This means that your initialization file, if you want one, can
       contain your own personal settings, definitions, and preferences,
       rather than 600 lines of "standard" setups.
     * If you still want the services directory, you can either TAKE the
       standard initialization file (which must be named anything other
       than $HOME/.kermrc to avoid being executed automatically every time
       you start Kermit), or you can make it a kerbang script and execute
       it "directly" (the [172]makefile install target does this for you
       by putting ckermit.ini in the same directory as the Kermit binary,
       adding the appropriate Kerbang line to the top, and giving it
       execute permission).

   In fact, you can put any number of kerbang scripts in your PATH to
   start up C-Kermit in different ways, to have it adopt certain settings,
   make particular connections, execute complicated scripts, whatever you
   want.

5.2. Text Files

   These are entirely optional. Many of them are to be found at the Kermit
   website in HTML form (i.e. as Web pages with clickable links, etc), and
   very likely also more up to date. Plain-text files that correspond to
   Web pages were simply "dumped" by Lynx from the website to plain ASCII
   text. The format is whatever Lynx uses for this purpose. If you wish,
   you can install them on your computer as described in the [173]next
   section.

   [174]COPYING.TXT
          Copyright notice, permissions, and disclaimer.

   [175]ckermit.ini
          The standard initialization file, intended more for reference
          (in most cases) than actual use; see [176]Section 5.1.

   [177]ckermod.ini
          A sample customization file.

   [178]ckermit70.txt
          Supplement to [179]Using C-Kermit for version 7.0. Available on
          the Kermit website as:
          [180]http://www.columbia.edu/kermit/ckermit70.html

   [181]ckermit80.txt
          Supplement to [182]Using C-Kermit for version 8.0. Available on
          the Kermit website as:
          [183]http://www.columbia.edu/kermit/ckermit80.html

   [184]ckcbwr.txt
          The general C-Kermit hints and tips ("beware") file. Available
          on the Kermit website as:
          [185]http://www.columbia.edu/kermit/ckcbwr.html

   [186]ckubwr.txt
          The Unix-specific C-Kermit hints and tips file. Available on the
          Kermit website as:
          [187]http://www.columbia.edu/kermit/ckubwr.html

   [188]ckuins.txt
          Unix C-Kermit Installation Instructions (this file). Available
          on the Kermit website as:
          [189]http://www.columbia.edu/kermit/ckuins.html

   [190]ckccfg.txt
          C-Kermit compile-time configuration options. Available on the
          Kermit website as:
          [191]http://www.columbia.edu/kermit/ckccfg.html

   [192]ckcplm.txt
          The C-Kermit program logic manual. Available on the Kermit
          website as:
          [193]http://www.columbia.edu/kermit/ckcplm.html

   [194]ca_certs.pem
          Certificate Authority certificates for secure connections (see
          [195]Section 16).

5.3. Installing the Kermit Files

   There is an "install" target in the [196]makefile that you can use if
   you wish. However, since every site has its own layout and
   requirements, it is often better to install the Kermit files by hand.
   You don't have to use the makefile install target to install C-Kermit.
   This is especially true since not all sites build C-Kermit from source,
   and therefore might not even have the makefile. But you should read
   this section in any case.

     If your computer already has an older version of C-Kermit installed,
     you should rename it (e.g. to "kermit6" or "kermit7") so in case you
     have any trouble with the new version, the old one is still
     available.

   In most cases, you need to be root to install C-Kermit, if only to gain
   write access to directories in which the binary and manual page are to
   be copied. The C-Kermit binary should be installed in a directory that
   is in the users' PATH, but that is not likely to be overwritten when
   you install a new version of the operating system. A good candidate
   would be the /usr/local/bin/ directory, but the specific choice is site
   dependent. Example (assuming the appropriate Kermit binary is stored in
   your current directory as "wermit", e.g. because you just built it from
   source and that's the name the makefile gave it):

mv wermit /usr/local/bin/kermit
chmod 755 /usr/local/bin/kermit

   or (only after you finish reading this section!) simply:

make install

   IMPORTANT: IF C-KERMIT IS TO BE USED FOR DIALING OUT, you must also do
   something to give it access to the dialout devices and lockfile
   directories. The 'install' target does not attempt to set Kermit's
   owner, group, and permissions to allow dialing out. This requires
   privileges, open eyes, and human decision-making. Please read
   [197]Sections 10 and [198]11 below, make the necessary decisions, and
   then implement them by hand as described in those sections.

   You should also install the man page, which is called ckuker.nr, in the
   man page directory for local commands, such as /usr/man/man1/, renamed
   appropriately, e.g. to kermit.1. This is also taken care of by "make
   install".

   Optionally, the text files listed in the [199]previous section can be
   placed in a publicly readable directory. Suggested directory names are:

/usr/local/doc/kermit/
/usr/local/lib/kermit/
/usr/share/lib/kermit/
/opt/kermit/doc/

   (or any of these without the "/kermit"). Upon startup, C-Kermit checks
   the following environment variables whose purpose is to specify the
   directory where the C-Kermit text files are, in the following order:

K_INFO_DIRECTORY
K_INFO_DIR

   If either of these is defined, C-Kermit checks for the existence of the
   ckubwr.txt file (Unix C-Kermit Hints and Tips). If not found, it checks
   the directories listed above (both with and without the "/kermit") plus
   several others to see if they contain the ckubwr.txt file. If found,
   various C-Kermit messages can refer the user to this directory.

   Finally, if you want to put the source code files somewhere for people
   to look at, you can do that too.

5.4. The Makefile Install Target

   The makefile "install" target does almost everything for you if you
   give it the information it needs by setting the variables described
   below. You can use this target if:

     * You downloaded the [200]complete C-Kermit archive and built
       C-Kermit from source; or:
     * You downloaded an [201]individual C-Kermit binary and the
       [202]C-Kermit text-file archive, and your computer has a "make"
       command.

   Here are the parameters you need to know:

   BINARY
          Name of the binary you want to install as "kermit". Default:
          "wermit".

   prefix
          (lower case) If you define this variable, its value is prepended
          to all the following xxxDIR variables (8.0.211 and later).

   DESTDIR
          If you want to install the Kermit files in a directory structure
          like /opt/kermit/bin/, /opt/kermit/doc/, /opt/kermit/src/, then
          define DESTIR as the root of this structure; for example,
          /opt/kermit. The DESTDIR string should not end with a slash. By
          default, DESTDIR is not defined. If it is defined, but the
          directory does not exist, the makefile attempts to create it,
          which might require you to be root. Even so, this can fail if
          any segments in the path except the last one do not already
          exist. WARNING: If the makefile creates any directories, it
          gives them a mode of 755, and the default owner and group.
          Modify these by hand if necessary.

   BINDIR
          Directory in which to install the Kermit binary (and the
          standard C-Kermit initialization file, if it is found, as a
          Kerbang script). If DESTDIR is defined, BINDIR must start with a
          slash. BINDIR must not end with a slash. If DESTDIR is defined,
          BINDIR is a subdirectory of DESTDIR. If BINDIR does not exist,
          the makefile attempts to create it as with DESTDIR. Default:
          /usr/local/bin.

   MANDIR
          Directory in which to install the C-Kermit manual page as
          "kermit" followed by the manual-chapter extension (next item).
          Default: /usr/man/man1. If MANDIR is defined, the directory must
          already exist.

   MANEXT
          Extension for the manual page. Default: 1 (digit one).

   SRCDIR
          Directory in which to install the C-Kermit source code. If
          DESTDIR is defined, this is a subdirectory of DESTDIR. Default:
          None.

   CERTDIR
          For secure builds only: Directory in which to install the
          ca_certs.pem file. This must be the verification directory used
          by programs that use the SSL libraries at your site. Default:
          none. Possibilities include: /usr/local/ssl, /opt/ssl,
          /usr/lib/ssl, . . .     If CERTDIR is defined, the directory
          must already exist.

   INFODIR
          Directory in which to install the C-Kermit text files. If
          DESTDIR is defined, this is a subdirectory of DESTDIR. Default:
          None. If INFODIR is defined but does not exist, the makefile
          attempts to create it, as with DESTDIR.

   Examples:

   make install
          Installs "wermit" as /usr/local/bin/kermit with permissions 755,
          the default owner and group, and no special privileges. The
          manual page is installed as /usr/man/man1/kermit.1. Text files
          are not copied anywhere, nor are the sources.

   make MANDIR= install
          Just like "make install" but does not attempt to install the
          manual page.

   make DESTDIR=/opt/kermit BINDIR=/bin SRCDIR=/src INFODIR=/doc install
          Installs the Kermit binary "wermit" as /opt/kermit/bin/kermit,
          puts the source code in /opt/kermit/src, and puts the text files
          in /opt/kermit/doc, creating the directories if they don't
          already exist, and puts the man page in the default location.

   make BINDIR=/usr/local/bin CERTDIR=/usr/local/ssl install
          Installs the Kerberized Kermit binary "wermit" as
          /usr/local/bin/kermit, puts the CA Certificates file in
          /usr/local/ssl/, and the man page in the normal place.

   For definitive information, see the makefile. The following is
   excerpted from the 8.0.211 makefile:

# The following symbols are used to specify library and header file locations
# Redefine them to the values used on your system by:
# . editing this file
# . defining the values on the command line
# . defining the values in the environment and use the -e option
#
prefix  = /usr/local
srproot = $(prefix)
sslroot = $(prefix)
manroot = $(prefix)

K4LIB=-L/usr/kerberos/lib
K4INC=-I/usr/kerberos/include
K5LIB=-L/usr/kerberos/lib
K5INC=-I/usr/kerberos/include
SRPLIB=-L$(srproot)/lib
SRPINC=-I$(srproot)/include
SSLLIB=-L$(sslroot)/ssl/lib
SSLINC=-I$(sslroot)/ssl/include
...
WERMIT = makewhat
BINARY = wermit
DESTDIR =
BINDIR = $(prefix)/bin
MANDIR = $(manroot)/man/man1
MANEXT = 1
SRCDIR =
INFODIR =
CERTDIR =

6. INSTALLING UNIX C-KERMIT FROM DOS-FORMAT DISKETTES

   [ [203]Top ] [ [204]Contents ] [ [205]Next ] [ [206]Previous ]

     This section is obsolete. We don't distribute C-Kermit on diskettes
     any more because (a)there is no demand, and (b) it no longer fits.

   If you received a DOS-format diskette containing a binary executable
   C-Kermit program plus supporting text files, be sure to chmod +x the
   executable before attempting to run it.

   In version 5A(190) and later, all the text files on the C-Kermit
   DOS-format diskettes are in Unix format: LF at the end of each line
   rather than CRLF. This means that no conversions are necessary when
   copying to your Unix file system, and that all the files on the
   diskette, text and binary, can be copied together. The following
   comments apply to the DOS-format diskettes furnished with version
   5A(189) and earlier or to other DOS-format diskettes you might have
   obtained from other sources.

   If you have received C-Kermit on MS-DOS format diskettes (such as those
   distributed by Columbia University), you should make sure that your
   DOS-to-Unix conversion utility (such as "dosread") both: (1) changes
   line terminators in all files from carriage-return linefeed (CRLF) to
   just linefeed (LF) (such as "dosread -a") and remove any Ctrl-Z's, and
   (2) that all filenames are converted from uppercase to lowercase. If
   these conversions were not done, you can use the following shell script
   on your Unix system to do them:

---(cut here)---
#!/bin/sh
#
# Shell script to convert C-Kermit DOS-format files into Unix format.
# Lowercases the filenames, strips out carriage returns and Ctrl-Z's.
#
x=$1 # the name of the source directory
y=$2 # the name of the target directory if [ $# -lt 2 ]; then
  echo "usage: $0 source-directory target-directory"
  exit 1
fi
if cd $1 ; then
  echo "Converting files from $1 to $2"
else
  echo "$0: cannot cd to $1"
  exit 1
fi
for i in *; do
  j=`echo $i | tr 'A-Z' 'a-z'`
  echo $x/$i =\> $y/$j
  tr -d '\015\032' < $i > $y/$j
done
---(cut here)---

   Cut out this shell script, save it as "convert.sh" (or any other name
   you prefer), then "chmod +x convert.sh". Then, create a new, empty
   directory to put the converted files in, and then "convert.sh /xxx
   /yyy" where /xxx is the name of the directory where the PC-format files
   are, and /yyy is the name of the new, empty directory. The converted
   files will appear in the new directory.

7. CHECKING THE RESULTS

   [ [207]Top ] [ [208]Contents ] [ [209]Next ] [ [210]Previous ]

   First some quick checks for problems that can be easily corrected by
   recompiling with different options:

   DIRECTORY listing is garbage
          Permissions, size, and date are random garbage (but the
          filenames are correct) in a C-Kermit DIRECTORY listing. On some
          platforms, the lstat() function is present but simply doesn't
          work; try adding -DNOLSTAT to CFLAGS and rebuild. If that
          doesn't fix it, also add -DNOLINKBITS. If it's still not fixed,
          remove -DNOLSTAT and -DNOLINKBITS and add -DNOSYMLINK.

   curses
          When you make a connection with C-Kermit and transfer files
          using the fullscreen (curses) file-transfer display, and then
          get the C-Kermit> prompt back afterwards, do characters echo
          when you type them? If not, the curses library has altered the
          buffering of /dev/tty. Try rebuilding with KFLAGS=-DCK_NEWTERM.
          If it already has -DCK_NEWTERM in CFLAGS, try removing it. If
          that doesn't help, then rebuild with -DNONOSETBUF (yes, two
          NO's). If none of this works (and you can't fix the code), then
          either don't use the fullscreen display, or rebuild with
          -DNOCURSES.

   Ctrl-L or any SCREEN command crashes C-Kermit:
          Rebuild with -DNOTERMCAP.

   No prompt after CONNECT:
          After escaping back from CONNECT mode, does your C-Kermit>
          prompt disappear? (Yet, typing "?" still produces a command
          list, etc) In that case, add -DCKCONINTB4CB to CFLAGS and
          rebuild.

   Here is a more thorough checklist can use to tell whether your version
   of C-Kermit was built correctly for your Unix system, with hints on how
   to fix or work around problems:

    a. Start C-Kermit (usually by typing "./wermit" in the directory where
       you ran the makefile). Do you see the C-Kermit> prompt? If not,
       C-Kermit incorrectly deduced that it was running in the background.
       The test is in conbgt() in [211]ckutio.c. If you can fix it for
       your system, please send in the fix (Hint: read about "PID_T"
       below). Otherwise, you can force C-Kermit to foreground mode by
       starting it with the -z command line option, as in "kermit -z", or
       giving the interactive command SET BACKGROUND OFF.
    b. When you type characters at the C-Kermit prompt, do they echo
       immediately? If not, something is wrong with concb() and probably
       the other terminal mode settings routines in [212]ckutio.c. Be sure
       you have used the most appropriate make entry.
    c. At the C-Kermit> prompt, type "send ./?". C-Kermit should list all
       the files in the current directory. If not, it was built for the
       wrong type of Unix file system. Details below. In the meantime, try
       SET WILDCARD-EXPANSION SHELL as a workaround.
    d. CD to a directory that contains a variety of files, symlinks, and
       subdirectories and give a DIRECTORY command at the C-Kermit>
       prompt. Do the permissions, size, and date appear correct? If not
       see [213]Section 4.0.
    e. Assuming your platform supports long file names, create a file with
       a long name in your current directory, e.g.:

$ touch thisisafilewithaveryveryveryveryveryveryveryverylooooooooongname

       (you might need to make it longer than this, perhaps as long as 257
       or even 1025 characters).
       Check with ls to see if your version of Unix truncated the name.
       Now start C-Kermit and type "send thisis<ESC>". Does Kermit
       complete the name, showing the same name as ls did? If not, wrong
       filesystem. Read on.
    f. Make sure that Kermit has the maximum path length right. Just type
       SHOW FILE and see what it says about this. If it is too short,
       there could be some problems at runtime. To correct, look in
       [214]ckcdeb.h to see how the symbol CKMAXPATH is set and make any
       needed adjustments.
    g. Send a file to your new Kermit program from a different Kermit
       program that is known to work. Is the date/timestamp of the new
       file identical to the original? If not, adjustments are needed in
       zstrdt() in [215]ckufio.c.
    h. Go to another computer (Computer B) from which you can send files
       to C-Kermit. Connect Computer B to the computer (A) where you are
       testing C-Kermit. Then:
    i. Send a file from B to A. Make sure it transferred OK and was
       created with the the right name.
    j. Send a file from B to A, specifying an "as-name" that is very, very
       long (longer than the maximum name length on computer A). Check to
       make sure that the file was received OK and that its name was
       truncated to Computer A's maximum length. If not, check the
       MAXNAMLEN definition in [216]ckufio.c.
    k. Tell C-Kermit on Computer A to "set receive pathnames relative" and
       then send it a file from Computer B specifying an as-name that
       contains several directory segments:

send foo dir1/dir2/dir3/foo

       Check to make sure that dir1/dir2/dir3/foo was created in Computer
       A's current directory (i.e. that three levels of directories were
       created).
    l. Repeat step k, but make each path segment in the pathname longer
       than Computer A's maximum name length. Make sure each directory
       name, and the final filename, were truncated properly.
    m. Type Ctrl-C (or whatever your Unix interrupt character is) at the
       prompt. Do you get "^C..." and a new prompt? If instead, you get a
       core dump (this shouldn't happen any more) "rm core" and then
       rebuild with -DNOCCTRAP added to your CFLAGS. If it did work, then
       type another Ctrl-C. If this does the same thing as the first one,
       then Ctrl-C handling is OK. Otherwise, the SIGINT signal is either
       not getting re-armed (shouldn't happen) or is being masked off
       after the first time it is caught, in which case, if your Unix is
       POSIX-based, try rebuilding C-Kermit with -DCK_POSIX_SIG.
    n. Type Ctrl-Z (or whatever your Unix suspend character is) to put
       C-Kermit in the background. Did it work? If nothing happened, then
       (a)your version of Unix does not support job control, or (b) your
       version of C-Kermit was probably built with -DNOJC. If your session
       became totally frozen, then you are probably running C-Kermit on a
       Unix version that supports job control, but under a shell that
       doesn't. If that's not the case, look in the congm() and psuspend()
       routines in [217]ckutio.c and see if you can figure out what's
       wrong. If you can't, rebuild with -DNOJC.
    o. Give a SET LINE command for a dialout device, e.g. "set line
       /dev/tty00". If you got some kind of permission or access denied
       message, go read [218]Section 10 and then come back here.
    p. After giving a successful SET LINE command, type "show comm" to see
       the communication parameters. Do they make sense?
    q. Type "set speed ?" and observe the list of available speeds. Is it
       what you expected? If not, see [219]Section 2) of the
       [220]Configurations Options document.
    r. Give a SET SPEED command to change the device's speed. Did it work?
       (Type "show comm" again to check.)
    s. Try dialing out: SET MODEM TYPE , SET LINE , SET SPEED , DIAL . If
       it doesn't work, keep reading. After dialing, can you REDIAL?
    t. If your version was built with TCP/IP network support, try the
       TELNET command.
    u. Transfer some files in remote mode on incoming asynchronous serial
       (direct or modem) connections, and on incoming network (telnet,
       rlogin, terminal server) connections. If you get lots of errors,
       try different SET FLOW settings on the remote Kermit program.
    v. Establish a serial connection from C-Kermit to another computer
       (direct or dialed) and transfer some files. If you have network
       support, do the same with a network connection.
    w. If your version was built with fullscreen file transfer display
       support, check that it works during local-mode file transfer. Also,
       check C-Kermit's operation afterwards: is the echoing funny? etc
       etc. If there are problems, see [221]Section 4.
    x. If your version was built with script programming language support,
       TAKE the ckedemo.ksc file to give it a workout.
    y. Does C-Kermit interlock correctly with UUCP-family programs (cu,
       tip, uucp, etc)? If not, read the section [222]DIALING OUT AND
       COORDINATING WITH UUCP below.
    z. Modem signals... Give a SET LINE command to a serial device and
       then type the SHOW MODEM command. If it says "Modem signals
       unavailable in this version of Kermit", then you might want to look
       at the ttgmdm() routine in [223]ckutio.c and add the needed code --
       if indeed your version of Unix provides a way to get modem signals
       (some don't; e.g. modem signals are a foreign concept to POSIX,
       requiring politically incorrect workarounds).
   aa. If it says "Modem signals unavailable", then it is likely that the
       API for getting modem signals is provided, but it doesn't actually
       do anything (e.g. ioctl(ttyfd,TIOCMGET,&x) returns EINVAL).
   ab. In any case, it still should be able to manipulate the DTR signal.
       To test, SET LINE , SET MODEM NONE, and HANGUP. The DTR light
       should go out momentarily. If it doesn't, see if you can add the
       needed code for your system to the tthang() routine in
       [224]ckutio.c.
   ac. If your version of Kermit has the SET FLOW RTS/CTS command, check
       to see if it works: give Kermit this command, set your modem for
       RTS/CTS, transfer some files (using big packet and window sizes)
       and watch the RTS and CTS lights on the modem. If they go on and
       off (and Kermit does not get packet errors), then it works. If your
       version of Kermit does not have this command, but your version of
       Unix does support hardware flow control, take a look at the
       tthflow() command in [225]ckutio.c and see if you can add the
       needed code (see the section on [226]HARDWARE FLOW CONTROL below).
       (And please [227]send back any added code, so that others can
       benefit from it and it can be carried forward into future
       releases.)
   ad. If C-Kermit starts normally and issues its prompt, echoing is
       normal, etc, but then after returning from a CONNECT session, the
       prompt no longer appears, try rebuilding with -DCKCONINTB4CB.
   ae. (8.0.206 or later) Type some commands at the C-Kermit prompt. Can
       you use the Up-arrow and Down-arrow keys on your keyboard to access
       Kermit's command history? If not, and you're a programmer, take a
       look at the USE_ARROWKEYS sections of ckucmd.c.

8. REDUCING THE SIZE OF THE EXECUTABLE PROGRAM IMAGE

   [ [228]Top ] [ [229]Contents ] [ [230]Next ] [ [231]Previous ]

   Also see: [232]C-Kermit Configuration Options

    a. Many of C-Kermit's options and features can be deselected at
       compile time. The greatest savings at the least sacrifice in
       functionality is to disable the logging of debug information by
       defining NODEBUG during compilation. See the [233]Configurations
       Options document for further information.
    b. Use shared libraries rather than static linking. This is the
       default on many Unix systems anyway. However, executables built for
       dynamic linking with shared libraries are generally not portable
       away from the machine they were built on, so this is recommended if
       the binary is for your use only.
    c. Most Unix systems have a "strip" command to remove symbol table
       information from an executable program image. "man strip" for
       further information. The same effect can be achieved by including
       "-s" among the link flags when building C-Kermit.
    d. SCO, Interactive, and some other Unix versions have an "mcs"
       command. "mcs -d wermit" can be used to delete the contents of the
       ".comment" section from the executable program image.
    e. Many modern optimizers can be instructed to optimize for space
       rather than execution efficiency. Check the CFLAGS in the makefile
       target, adjust as desired.

9. UNIX VERSIONS

   [ [234]Top ] [ [235]Contents ] [ [236]Next ] [ [237]Previous ]

   SECTION CONTENTS

9.1 [238]Standards
     9.1.1. [239]POSIX
     9.1.2. [240]ANSI C
     9.1.3. [241]Other Standards
9.2. [242]Library Issues
9.3. [243]Unix File System Peculiarities
9.4. [244]Hardware Flow Control
9.5. [245]Terminal Speeds
9.6. [246]Millisecond Sleeps
9.7. [247]Nondestructive Input Buffer Peeking
9.8. [248]Other System-Dependent Features
9.9. [249]Terminal Interruption

   There are several major varieties of Unix: Bell Laboratories Seventh
   Edition, AT&T System V, Berkeley Standard Distribution (BSD), and
   POSIX. Each has many, many subvarieties and descendents, and there are
   also hybrids that exhibit symptoms of two or more varieties, plus
   special quirks of their own.

   Seventh edition versions of C-Kermit include the compile-time option
   -DV7 in the CFLAGS string in the makefile target. Various V7-based
   implementations are also supported: -DCOHERENT, -DMINIX, etc.

   AT&T-based versions of Unix Kermit include the compile-time option
   -DATTSV (standing for AT&mp;T Unix System V). This applies to System
   III and to System V up to and including Release 2. For System V Release
   3, the flag -DSVR3 should be used instead (which also implies -DATTSV).
   This is because the data type of signal() and several other functions
   was changed between SVR2 and SVR3. For System V Release 4, include
   -DSVR4 because of changes in UUCP lockfile conventions; this also
   implies -DSVR3 and -DATTSV.

   For BSD, the flag -BSDxx must be included, where xx is the BSD version
   number, for example BSD4 (for version 4.2 or later, using only 4.2
   features), -DBSD41 (for BSD 4.1 only), -DBSD43 (for 4.3), -DBSD29 (BSD
   2.9 for DEC PDP-11s). -DBSD44 is for 4.4BSD, which is the basis of
   FreeBSD, NetBSD, OpenBSD, BSDI, and Mac OS X, and which contains many
   POSIX features, and has little relation to 4.3BSD and earlier.

   For POSIX, include the flag -DPOSIX. POSIX defines a whole new set of
   terminal i/o functions that are not found in traditional AT&T or
   Berkeley implementations, and also defines the symbol _POSIX_SOURCE,
   which is used in many system and library header files, mainly to
   disable non-POSIX (i.e. useful) features.

   Note (circa 1997): In order to enable serial speeds higher than 38400
   bps, it is generally necessary to add -DPOSIX (among other things),
   since the older terminal APIs can not accommodate the new speeds -- out
   o' bits. But this often also means wholesale conversion to POSIX APIs.
   In general, just try adding -DPOSIX and then see what goes wrong. Be
   wary of features disappearing: when _POSIX_SOURCE is defined, all sorts
   of things that were perfectly OK before suddenly become politically
   incorrect -- like reading modem signals, doing hardware flow control,
   etc. POSIX was evidently not designed with serial communication in
   mind!

   Case in point: In UnixWare 7.0, #define'ing POSIX causes strictness
   clauses in the header files to take effect. These prevent <sys/time.h>
   from defining the timeval and timezone structs, which are needed for
   all sorts of things (like select()). Thus, if we want the high serial
   speeds, we have to circumvent the POSIX clauses.

   Similarly in SCO OpenServer R5.0.4 where, again, we must use the POSIX
   APIs to get at serial speeds higher than 38400, but then doing so
   removes hardware flow control -- just when we need it most! In cases
   like this, dirty tricks are the only recourse (search for SCO_OSR504 in
   [250]ckutio.c for examples).

   For reasons like this, Unix implementations tend to be neither pure
   AT&T nor pure BSD nor pure POSIX, but a mixture of two or more of
   these, with "compatibility features" allowing different varieties of
   programs to be built on the same computer. In general, Kermit tries not
   to mix and match but to keep a consistent repertoire throughout.
   However, there are certain Unix implementations that only work when you
   mix and match. For example, the Silicon Graphics IRIX operating system
   (prior to version 3.3) is an AT&T Unix but with a BSD file system. The
   only way you can build Kermit successfully for this configuration is to
   include -DSVR3 plus the special option -DLONGFN, meaning "pretend I was
   built with -DBSDxx when it's time to compile file-related code". See
   the "iris" makefile target.

9.1. Standards

   [ [251]Top ] [ [252]Section Contents ] [ [253]Contents ] [ [254]Next ]

   SUBSECTION CONTENTS

9.1.1. [255]POSIX
9.1.2. [256]ANSI C
9.1.3. [257]Other Standards

   In edits 166-167 (1988-89), C-Kermit was heavily modified to try to
   keep abreast of new standards while still remaining compatible with old
   versions of C and Unix. There are two new standards of interest: ANSI C
   (as described in Kernighan and Ritchie, "The C Programming Language",
   Second Edition, Prentice Hall, 1988) and POSIX.1 (IEEE Standard 1003.1
   and ISO/IEC 9945-1, 1990, "Portable Operating System Interface"). These
   two standards have nothing to do with each other: you can build
   C-Kermit with a non-ANSI compiler for a POSIX system, or for a
   non-POSIX system with with an ANSI compiler.

9.1.1. POSIX

   POSIX.1 defines a repertoire of system functions and header files for
   use by C language programs. Most notably, the ioctl() function is not
   allowed in POSIX; all ioctl() functions have been replaced by
   device-specific functions like tcsetattr(), tcsendbreak(), etc.

   Computer systems that claim some degree of POSIX compliance have made
   some attempt to put their header files in the right places and give
   them the right names, and to provide system library functions with the
   right names and calling conventions. Within the header files,
   POSIX-compliant functions are supposed to be within #ifdef
   _POSIX_SOURCE..#endif conditionals, and non-POSIX items are not within
   these conditionals.

   If Kermit is built with neither -D_POSIX_SOURCE nor -DPOSIX, the
   functions and header files of the selected version of Unix (or VMS,
   etc) are used according to the CFLAGS Kermit was built with.

   If Kermit is built with -D_POSIX_SOURCE but not -DPOSIX, then one of
   the -DBSD or -DATTSV flags (or one that implies them) must also be
   defined, but it still uses only the POSIX features in the system header
   files. This allows C-Kermit to be built on BSD or AT&T systems that
   have some degree of POSIX compliance, but still use BSD or AT&T
   specific features.

   The dilimma is this: it is often necessary to define _POSIX_SOURCE to
   get at new or modern features, such as high serial speeds and the APIs
   to deal with them. But defining _POSIX_SOURCE also hides other APIs
   that Kermit needs, for example the ones dealing with modem signals
   (others are listed just below). Thus all sorts of hideous contortions
   are often required to get a full set of features.

   The POSIX standard does not define anything about uucp lockfiles. "make
   posix" uses NO (repeat, NO) lockfile conventions. If your
   POSIX-compliant Unix version uses a lockfile convention such as HDBUUCP
   (see below), use the "posix" entry, but include the appropriate
   lockfile option in your KFLAGS on the "make" command line, for example:

make posix "KFLAGS=-DHDBUUCP"

   POSIX.1 also lacks certain other features that Kermit needs. For
   example:

     * There is no defined way for an application to do wildcard matching
       of filenames. Kermit uses the inode in the directory structure, but
       POSIX.1 does not include this concept. (Later POSIX revisions
       include functions named (I think) glob() and fnmatch(), but these
       functions are not yet in Kermit, and might not be appropriate in
       any case.)
     * There is no POSIX mechanism for sensing or controlling modem
       signals, nor to enable RTS/CTS or other hardware flow control.
     * There is no select() for multiplexing i/o, and therefore no TCP/IP.
     * There is no way to check if characters are waiting in a
       communications device (or console) input buffer, short of trying to
       read them -- no select(), ioctl(fd,FIONREAD,blah), rdchk(), etc.
       This is bad for CONNECT mode and bad for sliding windows.
     * No way to do a millisecond sleep (no nap(), usleep(), select(),
       etc).
     * There is no popen().

   So at this point, there cannot be one single fully functional POSIX
   form of C-Kermit unless it also has "extensions", as do Linux, QNX,
   etc.

   More on POSIX (quoting from a newsgroup posting by Dave Butenhof):

     Standards tend to look at themselves as "enabling". So POSIX
     standards say that, in order to use POSIX functions, a program must
     define some macro that will put the development environment in
     "POSIX mode". For the ancient POSIX 1003.1-1990, the symbol is
     _POSIX_SOURCE. For recent revisions, it's _POSIX_C_SOURCE with an
     appropriate value. POSIX 1003.1-1996 says that, to use its features
     in a portable manner, you must define _POSIX_C_SOURCE=199506L before
     including any header files.

     But for Solaris, or Digital Unix, the picture is different. POSIX is
     one important but small part of the universe. Yet POSIX
     unconditionally and unambiguously REQUIRES that, when
     _POSIX_C_SOURCE=199506L, ALL of the functions and definitions
     required by the standard, and NO others (except in specific
     restricted namespaces, specifically "_" followed by an uppercase
     letter or "__" followed by a lowercase letter) shall be visible.
     That kinda puts a cramp on BSD and SVID support, because those
     require names that are not in the "protected" POSIX namespaces. It's
     ILLEGAL to make those symbols visible, unless you've done something
     else that's beyond the scope of POSIX to allow the system to infer
     that you didn't really mean it.

     In most cases, you should just compile, with no standards-related
     macros defined. The system will make available every interface and
     definition that isn't incompatible with the "main stream". There may
     indeed be cases where two standards cross, and you really can't use
     both together. But, in general, they play nicely together as long as
     you don't do anything rash -- like telling the system that it's not
     allowed to let them.

     In the area of threads, both Solaris and Digital Unix support
     incompatible thread APIs. We have POSIX and DCE, they have POSIX and
     UI. The nasty areas are in the _r routines and in some aspects of
     signal behavior. You cannot compile a single source file that uses
     both semantics. That's life. It sounds as if Solaris defaults to the
     UI variants, but allows you to define this _POSIX_THREAD_SEMANTICS
     to get around it. We default to POSIX, and allow you to define
     _PTHREAD_USE_D4 (automatically defined by the cc "-threads" switch)
     to select the DCE thread variants. That default, because you're
     operating outside of any individual standard, is really just a
     marketing decision.

9.1.2. ANSI C

   [ [258]Top ] [ [259]Contents ] [ [260]Section Contents ] [
   [261]Subsection Contents ] [ [262]Next ] [ [263]Previous ]

   The major difference between ANSI C and earlier C compilers is function
   prototyping. ANSI C allows function arguments to be checked for type
   agreement, and (when possible) type coercion in the event of a
   mismatch. For this to work, functions and their arguments must be
   declared before they are called. The form for function declarations is
   different in ANSI C and non-ANSI C (ANSI C also accepts the earlier
   form, but then does not do type checking).

   As of edit 167, C-Kermit tries to take full advantage of ANSI C
   features, especially function prototyping. This removes many bugs
   introduced by differing data types used or returned by the same
   functions on different computers. ANSI C features are automatically
   enabled when the symbol __STDC__ is defined. Most ANSI C compilers,
   such as GNU CC and the new DEC C compiler define this symbol
   internally.

   On the downside, ANSI C compilation increases the
   administrative/bureacratic burden, spewing out countless unneeded
   warnings about mismatched types, especially when we are dealing with
   signed and unsigned characters, requiring casts everywhere to shut up
   the mindless complaints -- there is no use for signed chars in Kermit
   (or probably anywhere else). Some compilers, mercifully, include a
   "treat all chars as unsigned" option, and when available it should be
   used -- not only to stop the warnings, but also to avoid unhelpful sign
   extension on high-bit characters.

   To force use of ANSI C prototypes, include -DCK_ANSIC on the cc command
   line. To disable the use of ANSI prototypes, include -DNOANSI.

9.1.3. Other Standards

   [ [264]Top ] [ [265]Contents ] [ [266]Section Contents ] [
   [267]Subsection Contents ] [ [268]Next ] [ [269]Previous ]

   As the years go by, standards with-which-all-must-comply continue to
   pile up: AES, XPG2, XPG3, XPG4, FIPS 151-2, successive generations of
   POSIX, OSF/1, X/Open, Spec 1170, UNIX95, Open Group UNIX98, ISO/IEC
   9945 parts 1-4, ISO 9899, 88Open, OS 99, Single Unix Specification
   (SUS, [270]IEEE 1003.1-2001, not to mention "mature standards" like V7,
   4.2/4.3BSD, System V R3 and R4 (SVID2 and SVID3), 4.4BSD (the basis for
   BSDI, OpenBSD, NetBSD, FreeBSD, Mac OS X etc), /usr/group, plus
   assorted seismic pronouncements of the neverending series of ephemeral
   corporate consortia, not to mention the libc-vs-glibc turmoil in the
   Linux arena and who knows what else.

   None of these standards simplifies life for portable applications like
   C-Kermit -- each one is simply one more environment to support (or
   circumvent, as in many cases these standards do more harm than good by
   denying access to facilities we need, e.g. as noted in above in
   [271]9.1.1).

9.2. Library Issues

   [ [272]Top ] [ [273]Contents ] [ [274]Section Contents ] [
   [275]Subsection Contents ] [ [276]Next ] [ [277]Previous ]

   On most modern platforms, applications are -- and often must be --
   dynamically linked. This has numerous advantages (smaller executables,
   ability to patch a library and thereby patch all applications that use
   it, etc), but also causes some headaches: most commonly, the library ID
   built into the executable at link time does not match the ID of the
   corresponding library on the target system, and so the loader refuses
   to let the application run.

   This problem only gets worse over time. In the Linux and *BSD world, we
   also have totally different libraries (each with their own names and
   numbering systems) that cover the same territory; for example, curses
   vs ncurses, libc versus glibc. Combinations proliferate and any given
   Unix computer might have any combination. For this reason it is
   becoming increasingly difficult to produce a "Linux binary" for a given
   architecture (e.g. PC or Alpha). There has to be a separate binary for
   (at least) every combination of curses vs ncurses and libc vs glibc.

   In such cases, the best advice is for every user to build C-Kermit from
   source code on the system where it will run. Too bad most commercial
   Unix vendors have stopped including C compilers with the operating
   system!

9.3. Unix File System Peculiarities

   [ [278]Top ] [ [279]Contents ] [ [280]Section Contents ] [ [281]Next ]
   [ [282]Previous ]

   Normally, including a BSD, System-V, POSIX, or DIRENT flag in the make
   entry selects the right file system code. But some versions of Unix are
   inconsistent in this regard, and building in the normal way either
   gives compiler or linker errors, or results in problems at runtime,
   typically failure to properly expand wildcard file specifications when
   you do something like "send *.*", or failure to recognize long
   filenames, as in "send filewithaveryveryveryveryverylongname".

   C-Kermit is supposed to know about all the various styles of Unix file
   systems, but it has to be told which one to use when you build it,
   usually in the makefile target CFLAGS as shown below, but you might
   also have to add something like -I/usr/include/bsd to CFLAGS, or
   something like -lbsd to LIBS.

   C-Kermit gives you the following CFLAGS switches to adapt to your file
   system's peculiarities:

-DDIRENT   - #include <dirent.h>
-DSDIRENT  - #include <sys/dirent.h>
-DNDIR     - #include <ndir.h>
-DXNDIR    - #include <sys/ndir.h>
-DRTU      - #include "/usr/lib/ndir.h", only if NDIR and XNDIR not defined.
-DSYSUTIMH - #include <sys/utime.h> for setting file creation dates.
-DUTIMEH   - #include <utime.h> for setting file creation dates.

   (Note, RTU should only be used for Masscomp RTU systems, because it
   also selects certain other RTU-specific features.)

   If none of these is defined, then <sys/dir.h> is used. IMPORTANT: If
   your system has the file /usr/include/dirent.h then be sure to add
   -DDIRENT to your makefile target's CFLAGS. "dirent" should be used in
   preference to any of the others, because it supports all the features
   of your file system, and the others probably don't.

   Having selected the appropriate directory header file, you might also
   need to tell Kermit how to declare the routines and variables it needs
   to read the directory. This happens most commonly on AT&T System-V
   based UNIXes, particularly System V R3 and earlier, that provide long
   file and directory names (longer than 14 characters). Examples include
   certain releases of HP-UX, DIAB DNIX, older versions of Silicon
   Graphics IRIX, and perhaps also MIPS. In this case, try adding -DLONGFN
   to your makefile target.

   Another problem child is <sys/file.h>. Most Unix C-Kermit versions need
   to #include this file from within [283]ckufio.c and [284]ckutio.c, but
   some not only do not need to include it, but MUST not include it
   because (a) it doesn't exist, or (b) it has already been included by
   some other header file and it doesn't protect itself against multiple
   inclusion, or (c) some other reason that prevents successful
   compilation. If you have compilation problems that seem to stem from
   including this file, then add the following switch to CFLAGS in your
   makefile target:

-DNOFILEH

   There are a few odd cases where <sys/file.h> must be included in one of
   the cku[ft]io.c files, but not the other. In that case, add the
   aforementioned switch, but go into the file that needs <sys/file.h> and
   add something like this:

#ifdef XXX       /* (where XXX is a symbol unique to your system) */
#undef NOFILEH
#endif /* XXX */

   before the section that includes <sys/file.h>.

   Kermit's SEND command expands wildcard characters "?" and "*" itself.
   Before version 5A, commands like "send *" would send all regular
   (non-directory) files, including "hidden files" (whose names start with
   "."). In version 5A, the default behavior is to match like the Bourne
   shell or the ls command, and not include files whose names start with
   dot. Such files can still be sent if the dot is included explicitly in
   the SEND command: "send .oofa, send .*". To change back to the old way
   and let leading wildcard characters match dot files, include the
   following in your CFLAGS:

-DMATCHDOT

   (In C-Kermit 6.0, there is also a command to control this at runtime.)

   Complaints about data-type mismatches:

     * If you get compile-time complaints about data type mismatches for
       process-ID related functions like getpid(), add -DPID_T=pid_t.
     * If you get compile-time complaints about data type mismatches for
       user ID related functions like getuid(), add -DUID_T=uid_t.
     * If you get compile-time complaints about data type mismatches for
       user-ID related functions like getgid(), add -DGID_T=gid_t.
     * If you get compile-time complaints about data type mismatches for
       getpwuid(), add -DPWID_T=uid_t (or whatever it should be).

   File creation dates: C-Kermit attempts to set the creation date/time of
   an incoming file according to the date/time given in the file's
   attribute packet, if any. If you find that the dates are set
   incorrectly, you might need to build Kermit with the -DSYSUTIMEH flag,
   to tell it to include <sys/utime.h>. If that doesn't help, look at the
   code in zstrdt() in [285]ckufio.c.

9.4. Hardware Flow Control

   [ [286]Top ] [ [287]Contents ] [ [288]Section Contents ] [ [289]Next ]
   [ [290]Previous ]

   Hardware flow control is a problematic concept in many popular Unix
   implementations. Often it is lacking altogether, and when available,
   the application program interface (API) to it is inconsistent from
   system to system. Here are some examples:

    a. POSIX does not support hardware flow control.
    b. RTS/CTS flow control support MIGHT be available for System V R3 and
       later if /usr/include/termiox.h exists (its successful operation
       also depends on the device driver, and the device itself, not to
       mention the [291]cable, etc, actually supporting it). If your
       SVR3-or-later Unix system does have this file, add:

-DTERMIOX

       to your CFLAGS. If the file is in /usr/include/sys instead, add:

-DSTERMIOX

       Note that the presence of this file does not guarantee that RTS/CTS
       will actually work -- that depends on the device-driver
       implementation (reportedly, many Unix versions treat
       hardware-flow-control related ioctl's as no-ops).
    c. Search ("grep -i") through /usr/include/*.h and
       /usr/include/sys/*.h for RTS or CTS and see what turns up. For
       example, in SunOS 4.x we find "CRTSCTS". Figuring out how to use it
       is another question entirely! In IBM AIX RS/6000 3.x, we have to
       "add" a new "line discipline" (and you won't find uppercase RTS or
       CTS symbols in the header files).
    d. NeXTSTEP and IRIX, and possibly others, support hardware flow
       control, but do not furnish an API to control it, and thus on these
       systems Kermit has no command to select it -- instead, a special
       device name must be used. (NeXTSTEP: /dev/cufa instead of /dev/cua;
       IRIX: /dev/ttyf00)

   See the routine tthflow() in [292]ckutio.c for details. If you find
   that your system offers hardware flow control selection under program
   control, you can add this capability to C-Kermit as follows:

    a. See if it agrees with one of the methods already used in tthflow().
       if not, add new code, appropriately #ifdef'd.
    b. Add -DCK_RTSCTS to the compiler CFLAGS in your makefile target or
       define this symbol within the appropriate #ifdefs in [293]ckcdeb.h.

   To illustrate the difficulties with RTS/CTS, here is a tale from Jamie
   Watson <jw@adasoft.ch>, who added the RTS/CTS code for the RS/6000,
   about his attempts to do the same for DEC ULTRIX:

     "The number and type of hardware signals available to/from a serial
     port vary between different machines and different types of serial
     interfaces on each machine. This means that, for example, there are
     virtually no hardware signals in or out available on the DECsystem
     3000/3100 series; on the DECsystem 5000/2xx series all modem signals
     in/out are present on both built-in serial ports; on the DECsystem
     5100 some ports have all signals and some only have some; and so
     on... It looks to me as if this pretty well rules out any attempt to
     use hardware flow control on these platforms, even if we could
     figure out how to do it. The confusion on the user level about
     whether or not it should work for any given platform or port would
     be tremendous. And then it isn't clear how to use the hardware
     signals even in the cases where the device supports them."

  9.5. Terminal Speeds

   [ [294]Top ] [ [295]Contents ] [ [296]Section Contents ] [ [297]Next ]
   [ [298]Previous ]

   The allowable speeds for the SET SPEED command are defined in
   [299]ckcdeb.h. If your system supports speeds that are not listed in
   "set speed ?", you can add definitions for them to ckcdeb.h.

   Then if the speed you are adding is one that was never used before in
   Kermit, such as 921600, you'll also need to add the appropriate
   keywords to spdtab[] in [300]ckuus3.c, and the corresponding case to
   ttsspd() in [301]ckutio.c.

  9.6. Millisecond Sleeps

   [ [302]Top ] [ [303]Contents ] [ [304]Section Contents ] [ [305]Next ]
   [ [306]Previous ]

   There is no standard for millisecond sleeps, but at least five
   different functions have appeared in various Unix versions that can be
   used for this purpose: nap() (mostly in System V), usleep() (found at
   least in SunOS and NeXT OS), select() (found in 4.2BSD and later, and
   part of any TCP/IP sockets library), nanosleep(), and sginap(). If you
   have any of these available, pick one (in this order of preference, if
   you have more than one):

-DSELECT: Include this in CFLAGS if your system has the select() function.
-DNAP:    Include this in CFLAGS if your system has the nap() function.
-USLEEP:  Include this in CFLAGS if your system has the usleep() function.

   NOTE: The nap() function is assumed to be a function that puts the
   process to sleep for the given number of milliseconds. If your system's
   nap() function does something else or uses some other units of time
   (like the NCR Tower 32, which uses clock-ticks), do not include -DNAP.

   Reportedly, all versions of System V R4 for Intel-based computers, and
   possibly also SVR3.2, include nap() as a kernel call, but it's not in
   the library. To include code to use it via syscall(3112,x), without
   having to include Xenix compatibility features, include the following
   compile-time option:

-DNAPHACK

  9.7. Nondestructive Input Buffer Peeking

   [ [307]Top ] [ [308]Contents ] [ [309]Section Contents ] [ [310]Next ]
   [ [311]Previous ]

   Some AT&T Unix versions have no way to check if input is waiting on a
   tty device, but this is a very important feature for Kermit. Without
   it, sliding windows might not work very well (or at all), and you also
   have to type your escape character to get Kermit's attention in order
   to interrupt a local-mode file transfer. If your system offers an
   FIONREAD ioctl, the build procedure should pick that up automatically
   and use it, which is ideal.

   If your system lacks FIONREAD but has a select() function, this can be
   used instead. If the build procedure fails to include it (SHOW FEATURES
   will list SELECT), then you can add it to your CFLAGS:

-DSELECT

   Conversely, if the build procedure tries to use select() when it really
   is not there, add:

-DNOSELECT

   Note: select() is not part of System V nor of POSIX, but it has been
   added to various System-V- and POSIX-based systems as an extension.

   Some System-V variations (SCO Xenix/UNIX/ODT and DIAB DNIX) include a
   rdchk() function that can be used for buffer peeking. It returns 0 if
   no characters are waiting and 1 if characters are waiting (but unlike
   FIONREAD, it does not tell the actual number). If your system has
   rdchk(), add:

-DRDCHK:  Include this in CFLAGS if your system has the rdchk() function.

   Otherwise, if your version of Unix has the poll() function (and the
   /usr/include/poll.h file) -- which appears to be a standard part of
   System V going back to at least SVR3, include:

-DCK_POLL

  9.8. Other System-Dependent Features

   [ [312]Top ] [ [313]Contents ] [ [314]Section Contents ] [ [315]Next ]
   [ [316]Previous ]

   Systems with <termios.h> might have the symbol IEXTEN defined. This is
   used to turn "extended features" in the tty device driver on and off,
   such as Ctrl-O to toggle output flushing, Ctrl-V to quote input
   characters, etc.

   In most Unix implementations, it should be turned off during Kermit
   operation, so if [317]ckutio.c finds this symbol, it uses it. This is
   necessary, at least, on BSDI. On some systems, however, IEXTEN is
   either misdefined or misimplemented. The symptom is that CR, when typed
   to the command processor, is echoed as LF, rather than CRLF. This
   happens (at least) on Convex/OS 9.1. The solution is to add the
   following symbol to the makefile target's CFLACS:

-DNOIEXTEN

   However, in at least one Unix implementation, QNX 4.21, IEXTEN must be
   set before hardware flow control can be used.

   In edits 177 and earlier, workstation users noticed a "slow screen
   writing" phenomenon during interactive command parsing. This was traced
   to a setbuf() call in [318]ckutio.c that made console (stdout) writes
   unbuffered. This setbuf() call has been there forever, and could not be
   removed without some risk. Kermit's operation was tested on the NeXT in
   edit 178 with the setbuf() call removed, and the slow-writing symptom
   was cured, and everything else (command parsing, proper wakeup on ?,
   ESC, Ctrl-U, and other editing characters, terminal emulation,
   remote-mode and local-mode file transfer, etc) seemed to work as well
   as or better than before. In subsequent edits, this change was made to
   many other versions too, with no apparent ill effects. To remove the
   setbuf() call for your version of Kermit, add:

-DNOSETBUF

   Later reports indicate that adding -DNOSETBUF has other beneficial
   effects, like cutting down on swapping when Kermit is run on
   workstations with small memories. But BEWARE: on certain small Unix
   systems, notably the AT&T 6300 and 3B1 (the very same ones that benefit
   from NOSETBUF), NOSETBUF seems to conflict with CK_CURSES. The program
   builds and runs OK, but after once using the curses display, echoing is
   messed up. In this case, we use a System-V specific variation in the
   curses code, using newterm() to prevent System V from altering the
   buffering. See makefile entries for AT&T 6300 and 3B1.

   The Unix version of C-Kermit includes code to switch to file descriptor
   zero (stdin) for remote-mode file transfer. This code is necessary to
   prevent Kermit from giving the impression that it is "idle" during file
   transfers, which, at some sites, can result in the job being logged out
   in the middle of an active file transfer by idle-job monitors.

   However, this feature can interfere with certain setups; for example,
   there is a package which substitutes a pty/tty pair for /dev/tty and
   sets file descriptor 0 to be read-only, preventing Kermit from sending
   packets. Or... When a Unix shell is invoked under the PICK environment,
   file descriptor 0 is inoperative.

   To remove this feature and allow Kermit to work in such environments,
   add the compile-time option:

-DNOFDZERO

   On some versions of Unix, earlier releases of C-Kermit were reported to
   render a tty device unusable after a hangup operation. Examples include
   IBM AIX on the RT PC and RS/6000. A typical symptom of this phenomenon
   is that the DIAL command doesn't work, but CONNECTing to the device and
   dialing manually do work. A further test is to SET DIAL HANGUP OFF,
   which should make dialing work once by skipping the pre-dial hangup.
   However, after the connection is broken, it can't be used any more:
   subsequent attempts to DIAL the same device don't work. The cure is
   usually to close and reopen the device as part of the hangup operation.
   To do this, include the following compile-time option:

-DCLSOPN

   Similarly, there is a section of code in ttopen(), which does another
   close(open()) to force the O_NDELAY mode change. On some systems, the
   close(open()) is required to make the mode change take effect, and
   apparently on most others it does no harm. But reportedly on at least
   one System V R4 implementation, and on SCO Xenix 3.2, the close(open())
   operation hangs if the device lacks carrier, EVEN THOUGH the CLOCAL
   characteristic has just been set to avoid this very problem. If this
   happens to you, add this to your CFLAGS:

-DNOCOTFMC

   or, equivalently, in your KFLAGS on the make command line. It stands
   for NO Close(Open()) To Force Mode Change.

   C-Kermit renames files when you give a RENAME command and also
   according to the current SET FILE COLLISION option when receiving
   files. The normal Unix way to rename a file is via two system calls:
   link() and unlink(). But this leaves open a window of vulnerability.
   Some Unix systems also offer an atomic rename(oldname,newname)
   function. If your version of Unix has this function, add the following
   to your CFLAGS:

-DRENAME

   C-Kermit predefines the RENAME for several Unix versions in
   [319]ckcdeb.h (SVR4, SUNOS41, BSD44, AIXRS, etc). You can tell if
   rename() is being used if the SHOW FEATURES command includes RENAME in
   the compiler options list. If the predefined RENAME symbol causes
   trouble, then add NORENAME to your CFLAGS. Trouble includes:

    a. Linker complains that _rename is an unresolved symbol.
    b. Linking works, but Kermit's RENAME command doesn't work (which
       happens because older versions of rename() might have their
       arguments reversed).

   If rename() is not used, then Kermit uses link()/unlink(), which is
   equivalent except it is not atomic: there is a tiny interval in which
   some other process might "do something" to one of the files or links.

   Some Unix systems (Olivetti X/OS, Amdahl UTS/V, ICL SVR3, etc) define
   the S_ISREG and S_ISDIR macros incorrectly. This is compensated for
   automatically in [320]ckufio.c. Other systems might have this same
   problem. If you get a compile-time error message regarding S_ISREG
   and/or S_ISDIR, add the following to your CFLAGS:

-DISDIRBUG

   Finally, here's a symbol you should NEVER define:

-DCOMMENT

   It's used for commenting out blocks of code. If for some reason you
   find that your compiler has COMMENT defined, then add -UCOMMENT to
   CFLAGS or KFLAGS! Similarly, some header files have been known to
   define COMMENT, in which case you must add "#undef COMMENT" to each
   C-Kermit source module, after all the #includes.

  9.9. Terminal Interruption

   [ [321]Top ] [ [322]Contents ] [ [323]Section Contents ] [ [324]Next ]
   [ [325]Previous ]

   When C-Kermit enters interactive command mode, it sets a Control-C
   (terminal keyboard interrupt = SIGINT) trap to allow it to return to
   the command prompt whenever the user types Control-C (or whatever is
   assigned to be the interrupt character). This is implemented using
   setjmp() and longjmp(). On some systems, depending on the machine
   architecture and C compiler and who knows what else, you might get
   "Memory fault (coredump)" or "longjmp botch" instead of the desired
   effect (this should not happen in 5A(190) and later). In that case, add
   -DNOCCTRAP to your CFLAGS and rebuild the program.

   Job control -- the ability to "suspend" C-Kermit on a Unix system by
   typing the "susp" character (normally Ctrl-Z) and then resume execution
   later (with the "fg" command) -- is a tricky business. C-Kermit must
   trap suspend signals so it can put the terminal back into normal mode
   when you suspend it (Kermit puts the terminal into various strange
   modes during interactive command parsing, CONNECT, and file transfer).
   Supporting code is compiled into C-Kermit automatically if <signal.h>
   includes a definition for the SIGTSTP signal. HOWEVER... some systems
   define this signal without supporting job control correctly. You can
   build Kermit to ignore SIGTSTP signals by including the -DNOJC option
   in CFLAGS. (You can also do this at runtime by giving the command SET
   SUSPEND OFF.)

     NOTE: As of version 5A(190), C-Kermit makes another safety check.
     Even if job control is available in the operating system (according
     to the numerous checks made in congm()), it will still disable the
     catching of SIGTSTP signals if SIGTSTP was set to SIG_IGN at the
     time C-Kermit was started.

   System V R3 and earlier systems normally do not support job control. If
   you have an SVR3 system that does, include the following option in your
   CFLAGS:

-DSVR3JC

   On systems that correctly implement POSIX signal handling, signals can
   be handled more reliably than in Bell, Berkeley, or AT&T Unixes. On
   systems (such as QNX) that are "strictly POSIX", POSIX signal handling
   *must* be used, otherwise no signal will work more than once. If you
   have POSIX-based system and you find that your version of Kermit
   responds to Ctrl-C (SIGINT) or Ctrl-Z (SIGTSTP) only once, then you
   should add the following option to your CFLAGS:

-DCK_POSIX_SIG

   But be careful; some POSIX implementations, notably 4.4BSD, include
   POSIX signal handling symbols and functions as "stubs" only, which do
   nothing. Look in <signal.h> for sigsetjmp and siglongjmp and read the
   comments.

10. DIALING OUT AND COORDINATING WITH UUCP

   [ [326]Top ] [ [327]Contents ] [ [328]Next ] [ [329]Previous ]

   The short version (general):

     In order for C-Kermit to be able to dial out from your Unix
     computer, you need to give it the same owner, group, and permissions
     as your other dialout programs, such as cu, tip, minicom, uucp,
     seyon, etc.

   The short version for Linux only:

     Since Red Hat 7.2, about 2002, Linux does not leave the lockfile
     handling to each application, but instead provides an external
     application, /usr/sbin/lockdev, that all applications should invoke
     when they need to access a serial port; lockdev locks and unlocks
     the port without requiring the application to have privileges, since
     the privileges on the lockfile directory are assigned to lockdev.
     C-Kermit 8.0.211 and later support this method. But C-Kermit still
     needs to be able to open the port itself, and therefore if the
     port's permissions do not allow read/write access to the general
     public, the general rule must still be followed: in the most common
     case, it must be SETGID to the group uucp (explained below). If a
     pre-8.0.211 version of C-Kermit is to be installed for use with
     serial ports on any version of Linux, it must still be installed as
     described in the following sections.

   The long version:

   Make sure your dialout line is correctly configured for dialing out (as
   opposed to login). The method for doing this is different for each kind
   of Unix. Consult your system documentation for configuring lines for
   dialing out (for example, Sun SPARCstation IPC users should read the
   section "Setting up Modem Software" in the Desktop SPARC Sun System and
   Network Manager's Guide, or the Terminals and Modems section of the HP
   manual, "Configuring HP-UX for Peripherals" (e.g. /usr/sbin/sam =>
   Peripheral Devices => Terminals and Modems => Add Modem).

   Unlike most other multiuser, multitasking operating systems, Unix
   allows multiple users to access the same serial device at the same
   time, even though there is no earthly reason why two users should do
   this. When they do, user A will read some of the incoming characters,
   and user B will read the others. In all likelihood, neither user will
   see them all. Furthermore, User B can hang up User A's call, and so
   one.

   Rather than change Unix to enforce exclusive access to serial devices
   such as ttys, when it might still have been possible, Unix developers
   opted for a "lock file" mechanism. Any process that wants to open a tty
   device should first check to see if a file of a certain name exists,
   and if so, not to open the device. If the file does not exist, the
   process creates the file and then opens the device. When the process
   closes the device, it destroys the lockfile. This procedure was
   originated for use with Unix's UUCP, CU, and TIP programs, and so these
   lockfiles are commonly called "UUCP lockfiles" (UUCP = Unix-to-Unix
   Copy Program).

   As you can imagine, this method is riddled with pitfalls:

     * If a process does not observe the prevailing lockfile convention,
       then it can interfere with other "polite" processes. And in fact,
       very few Unix applications or commands handle lockfiles at all; an
       original design goal of Unix was that "everything is a file", and
       countless utilities operate on files directly (by opening them) or
       indirectly through redirection of standard i/o, without creating or
       looking for lockfiles.
     * If a process crashes while it has the device open, the lockfile is
       left behind, preventing further processes from using the device.
     * Various versions of Unix use different names for the lockfiles, put
       them in different directories, with different owners and groups and
       permissions, and specify their contents differently.
     * On a given platform, the lockfile conventions may change from one
       Unix release to the next (for example, SunOS 4.0 to 4.1) or, in the
       case of Linux, across different distributions.
     * The same tty device might have more than one name, and most
       lockfile conventions don't allow for this. Similarly for symbolic
       links.

   In an attempt to address the problem of "stale" lockfiles, most UUCP
   implementations put the PID (Process ID) of the creating process in the
   lockfile. Thus, another process that wants to open the corresponding
   device can check not only for the lockfile itself, but also can check
   the PID for validity. But this doesn't work well either:

     * PIDs are stored in diverse formats that change with every new
       release (short, integer, long, or string in any of various
       formats). If the reading program does not follow the same
       convention as the writing program, it can diagnose a valid PID to
       be invalid, and therefore not honor the lock.
     * PIDs recycle. If the lockfile was created by PID 1234, which later
       crashed without removing the lockfile, and then a new process 1234
       exists a the time the lockfile is checked, the lockfile will be
       improperly taken as valid, and access to the device denied
       unnecessarily.

   Several techniques address the problem of multiple names for the same
   device:

     * Multiple lockfiles. For example, if the user opens a device through
       a symlink, a lockfile is created for both the symlink name and the
       true name (obtained from readlink()). However, when multiple
       drivers are installed for the same device (e.g. /dev/cua,
       /dev/cufa, etc), this approach won't work unless all applications
       *know* all the different names for the same device and make
       lockfiles for all of them, which is obviously not practical.
     * Lockfiles whose names are not based on the device name. These
       lockfiles generally have names like LK.inode/major/minor, where
       inode, major, and minor are numbers, which will always be the same
       for any physical device, no matter what its name. This form of
       lockfile is used in System V R4 and its derivatives, such as
       Solaris, UnixWare, etc. If lockfiles must be used (as opposed to,
       say, kernel-based locks), this would seem to be the most effective
       form.

   Most versions of Unix were not designed to accommodate third-party
   communications software; thus vendors of these Unix products feel no
   compunction about changing lockfile conventions from release to
   release, since they also change their versions of the cu, uucp, tip,
   etc, programs at the same time to match. And since the source code to
   these programs might not be published, it is difficult for makers of
   third-party products like C-Kermit to find out what the new conventions
   are. It also forces release of new versions of C-Kermit whenever the OS
   vendor makes a change like this.

   Some Unix vendors have taken a small step to simplify communications
   application development for their products: the inclusion of lockfile
   routines in the standard system C runtime libraries to shield the
   application from the details of lockfile management (IBM AIX is an
   example). When such routines are used, communications applications do
   not need modification when lockfile conventions change (although they
   will need recompiling if the routines are statically linked into the
   application). In the AIX example, the simple function calls ttylock(),
   ttyunlock(), and ttylocked() replace hundreds of lines of ugly code in
   C-Kermit that attempts to keep pace with every release of every Unix
   product over the last 20 years. Inclusion of ttylock() code occurs
   when:

-DUSETTYLOCK

   is included in the CFLAGS.

   If such routines are available, they should be used. The rest of this
   section applies when they are not.

   To fit in with UUCP and other Unix-based serial-port communication
   software, C-Kermit must have the same idea as your system's uucp, cu,
   and tip programs about what the UUCP lock directory is called, what the
   lockfile itself is called, and what its contents should be. In most
   cases, C-Kermit preprocessor flags create the appropriate configuration
   at compile time if the appropriate makefile target was used (see
   [330]ckutio.c). The following CFLAGS options can be used to override
   the built-in configuration:

   -DLCKDIR
          Tells Kermit that the UUCP lock directory is
          /usr/spool/uucp/LCK.

   -DACUCNTRL
          Tells Kermit to use the BSD 4.3 acucntrl() program to turn off
          getty (login) on the line before using it, and restore getty
          when done.

   -DHDBUUCP
          Include this if your system uses Honey DanBer UUCP, in which the
          lockfile directory and format are relatively standardized.

   -DLOCK_DIR=\\\"/xxx/yyy\\\"
          Gives the lock directory name explicitly. The triple quoting is
          necessary. For example:

CFLAGS= -DBSD4 -DLOCK_DIR=\\\"/usr/local/locks\\\" -DNODEBUG

          (NOTE: The triple quoting assumes this is a "top-level" make
          entry, and not a make entry that calls another one.)

   -DLFDEVNO The lockfile name uses the tty device inode and major and
          minor
          numbers: LK.dev.maj.min, as in Sys V R4, e.g. LK.035.044.008.

   When the LK.inode.major.minor form is used, a single lockfile is
   enough. Otherwise, a single lockfile rarely suffices. For example, in
   Linux, it is common to have a /dev/modem symbolic link to an actual
   dialout device, like /dev/cua0 or /dev/ttyS0, whose purpose is to hide
   the details of the actual driver from the user. So if one user opens
   /dev/modem, a lockfile called LCK..modem is created, which does not
   prevent another user from simulataneously opening the same device by
   its real name.

   On SCO Unix platforms, we have a slightly different problem: the same
   device is, by convention, known by "lowercase" and "uppercase" names,
   depending on whether it has modem control. So by convention,
   communications programs are supposed to create the lockfiles based on
   the lowercase name. But some programs don't follow this convention. In
   HP-UX, we have several different names for each serial device. And so
   on.

   For this reason, on platforms where the LK.inode.major.minor form is
   not used, C-Kermit also creates a secondary lockfile (which is simply a
   link to the first) if:

    a. The given device name is a symbolic link. The secondary link is
       based on the device's real name.
    b. On SCO: The device name is not a symbolic link, but it contains
       uppercase letters. The primary link is based on the lowercase name;
       the secondary link is based on the name that was given.
    c. On HP-UX: The device name starts with "cu". The primary link is
       based on the name that was given; the secondary link is based on
       the corresponding "ttyd" device, e.g. "LCK..cua0p0" and
       "LCK..ttyd0p0".

   NOTE: symlinks are not handled in HP-UX.

   Honey DanBer (HDB) UUCP, the basis of many UUCP implementations, has
   two characteristics:

    a. Lockfiles are kept in /usr/spool/locks/ (usually).
    b. A lockfile contains the process id (pid) in ASCII, rather than as
       an int.

   Non-HDB selections assume the lockfile contains the pid in int form
   (or, more precisely, in PID_T form, where PID_T is either int or pid_t,
   depending on your system's C library and header files). (b), by the
   way, is subject to interpretation: the numeric ASCII string may or may
   not be terminated by a newline, it may or may not have leading spaces
   (or zeros), and the number of leading spaces or zeros can differ, and
   the differences can be significant.

   Even if you build the program with the right lockfile option, you can
   still have problems when you try to open the device. Here are the error
   messages you can get from SET LINE, and what they mean:

    a. "Timed out, no carrier." This one is not related to lockfiles. It
       means that you have SET CARRIER ON xx, where xx is the number of
       seconds to wait for carrier, and carrier did not appear within xx
       seconds. Solution: SET CARRIER AUTO or OFF.
    b. "Sorry, access to lock denied." Kermit has been configured to use
       lockfiles, but (a)the lockfile directory is write-protected against
       you, or (b) it does not exist. The "access to lock denied" message
       will tell you the reason. If the directory does not exist, check to
       make sure Kermit is using the right name. Just because version n of
       your Unix used a certain lockfile directory is no gurantee that
       version n.1 does not use a different one. Workaround: ask the
       system administrator to install a symbolic link from the old name
       to the new name. Other solutions: (see below)
    c. "Sorry, access to tty device denied." The tty device that you
       specified in your SET LINE command is read/write protected against
       you. Solution: (see below)
    d. "Sorry, device is in use." The tty device you have specified is
       currently being used by another user. A prefatory message gives you
       an "ls -l" listing of the lockfile, which should show the username
       of the person who created it, plus a message "pid = nnn" to show
       you the process id of the user's program. Solutions: try another
       device, wait until the other user is finished, ask the other user
       to hurry up, or ask the system manager for help.
    e. "Sorry, can't open connection: reason". The device cannot be opened
       for some other reason, which is listed.
    f. "sh: /usr/lib/uucp/acucntrl: not found". This means your Kermit
       program was built with the -DACUCNTRL switch, but your computer
       system does not have the BSD 4.3 acucntrl program. Solution:
       install the acucntrl program if you have it, or rebuild Kermit
       without the -DACUCNTRL switch.

   There are two solutions for problems (b) and (c), both of which involve
   intervention by your Unix system administrator (superuser):

    a. Have the superuser change the permission of the lockfile directory
       and to the tty devices so that everyone on the system has
       read/write permission.

su% chmod 777 /usr/spool/locks (or whatever the path is)
su% chmod 666 /dev/ttyXX

       One risk here is that people can write lots of junk into the
       lockfile directory, delete other people's files in the lockfile
       directory, and intercept other people's data as it goes in and out
       of the tty device. The major danger here would be intercepting a
       privileged password. Of course, any user could write a short,
       ordinary, unprivileged program to do exactly the same thing if the
       tty device was world read/writeable. The other risk as that
       telephone calls are not controlled -- anybody on your system can
       make them, without having to belong to any particular group, and
       this could run up your phone bill.
    b. Use groups to regulate access. Normally the lockfile directory and
       and the dialout devices will have the same group (such as uucp). If
       so, then put everybody who's allowed to dial out into that group,
       and make sure that the lockfile directory and the tty devices have
       group read AND write permission. Example:

su% chmod 770 /usr/spool/locks (or whatever the path is)
su% chmod 660 /dev/ttyXX

       User whatever tool is available on your platform to add users to
       the appropropriate group (e.g. edit the /etc/group file).
    c. Have the superuser change Kermit to run setuid and/or setgid to the
       owner and/or group of the lockfile directory and the tty devices if
       necessary), typically uucp (see [331]next section), but NOT root.
       Example:

su% chown uucp kermit          - or -  chgrp uucp kermit
su% chmod u+s kermit (setuid)  - or -  chmod g+s kermit (setgid)

       and then make sure the lockfile directory, and the tty devices,
       have owner (setuid) and/or group (setgid) write permission. For
       example:

su% chmod o+rwx /usr/spool/uucp
su% chown uucp /dev/ttyXX ; chmod 600 /dev/ttyXX

       In some cases, the owner and group must be distinct; the key point
       is that read/write access is required to both the UUCP lockfile
       directory and the tty itself.

   If you make C-Kermit setuid or setgid to root, it refuses to run:

Fatal: C-Kermit setuid to root!

   Example:

crw-r-----   1 uucp     uucp       5,  67 Feb 11 06:23 /dev/cua3
drwxrwxr-x   3 root     uucp         1024 Feb 11 06:22 /var/lock

   requires suid uucp to get read/write access on /dev/cua3 and sgid to
   get read/write access on /var/lock (since you can't set Kermit's uid or
   gid to root).

     The reason Kermit can't be setuid or setgid to root has to do with
     the fact that some Unix OS's can't switch user or group IDs in that
     case. Unfortunately, the prohibition against making Kermit setuid or
     setgid to root means that Unix C-Kermit can't be used to make rlogin
     connections by non-root users. (The rlogin port is privileged, which
     is why the regular rlogin command is setuid root -- which is safe
     because the rlogin program never has to create or access files like
     Kermit does.)

   For the lockfile mechanism to achieve its desired purpose -- prevention
   of access to the same tty device by more than one process at a time --
   ALL programs on a given computer that open, read or write, and close
   tty devices must use the SAME lockfile conventions. Unfortunately, this
   is often not the case. Here is a typical example of how this can go
   wrong: In SunOS 4.0 and earler, the lockfile directory was
   /usr/spool/uucp; in 4.1 it was changed to /var/spool/locks in the quest
   for political correctness. Consequently, any third-party programs (such
   as C-Kermit) that were not modified to account for this change,
   recompiled, and reinstalled, did not use the same lockfiles as uucp,
   tip, etc, and so the entire purpose of the lockfile is defeated.

   What if your Unix system does not have UUCP installed? For example, you
   have a Unix workstation, and you do not use uucp, cu, or tip, or UUCP
   was not even supplied with your version of Unix (QNX is an example). In
   this case, you have two choices:

    a. If there may be more than one person running Kermit at the same
       time, competing for the same tty device, then create a special
       lockfile directory just for Kermit, for example, /usr/spool/kermit,
       and make sure you have read/write access to it. Then add the
       following to your makefile target CFLAGS, as shown earlier:

-DLOCK_DIR=\\\"/usr/spool/kermit\\\"

    b. If you are the only user on your workstation, and no other
       processes will ever be competing with Kermit for the dialout tty
       device, then add -DNOUUCP to your makefile target's CFLAGS and
       rebuild Kermit.

11. RUNNING UNIX C-KERMIT SETUID OR SETGID

   [ [332]Top ] [ [333]Contents ] [ [334]Next ] [ [335]Previous ]

   Even if you don't intend to run C-Kermit setuid, somebody else might
   come along and chown and chmod it after it has been built. You should
   be sure that it is built correctly to run setuid on your system. For
   POSIX and AT&T Unix based versions, you don't have to do anything
   special.

   For 4.2 and 4.3 BSD-based Unix versions, you normally need not add
   anything special to the makefile. The program assumes that the
   setreuid() and setregid() functions are available, without which we
   cannot switch back and forth between real and effective uids. If "make"
   complains that _setreuid or _setregid is/are not defined, add
   -DNOSETREU to CFLAGS. In this case it is very likely (but not certain)
   that you cannot protect ttys and lockfiles against people and have them
   run Kermit setuid.

   If make does not complain about this, you should find out whether your
   BSD version (4.3 or other systems like SunOS 4.x that claim to include
   BSD 4.3 compatibility) includes the saved-setuid feature (see long
   notes under edit 146 in ckc178.upd). If it does, then add -DSAVEDUID to
   CFLAGS.

     IMPORTANT NOTE: Most Unix system documentation will not give you the
     required information. To determine whether your Unix system supplies
     the the saved-original-effective-user/group-id feature, use the
     ckuuid.c program. Read and follow the instructions in the comments
     at the beginning.

   C-Kermit for 4.4BSD-based systems automatically use sete[ug]id(). See
   [336]ckutio.c.

   If you have a version of Unix that is not BSD-based, but which supplies
   the setreuid() and setregid() functions, and these are the only way to
   switch between real and effective uid, add -DSETREUID to your makefile
   target.

     WARNING: There are two calls to access() in [337]ckufio.c, by which
     Kermit checks to see if it can create an output file. These calls
     will not work correctly when (a)you have installed C-Kermit setuid
     or setgid on a BSD-based Unix system, and (b) the
     saved-original-effective-uid/gid feature is not present, and (c) the
     access() function always checks what it believes to be the real ID
     rather than the effective ID. This is the case, for example, in
     Olivetti X/OS and in NeXTSTEP. In such cases, you can force correct
     operation of access() calls by defining the symbol SW_ACC_ID at
     compile time in CFLAGS.

   If you have a version of Unix that does not allow a process to switch
   back and forth between its effective and real user and group ids
   multiple times, you probably should not attempt to run Kermit setuid,
   because once having given up its effective uid or gid (which it must do
   in order to transfer files, fork a shell, etc) it can never get it
   back, and so it can not use the original effective uid or gid to create
   or delete uucp lockfiles. In this case, you'll either have to set the
   permissions on your lockfile directory to make them publicly
   read/writable, or dispense with locking altogether.

   MORAL: Are you thoroughly sickened and/or frightened by all that you
   have just read? You should be. What is the real answer? Simple. Serial
   devices -- such as ttys and magnetic tapes -- in Unix should be opened
   with exclusive access only, enforced by the Unix kernel. Shared access
   has no conceivable purpose, legitimate or otherwise, except by
   privileged system programs such as getty. The original design dates
   from the late 1960s, when Unix was developed for laboratory use under a
   philosophy of trust by people within shouting distance of each other --
   but even then, no useful purpose was served by this particular form of
   openness; it was probably more of a political statement. Since the
   emergence of Unix from the laboratory into the commercial market, we
   have seen every vestige of openness -- but this one -- stripped away.
   I'd like to see some influential Unix maker take the bold step of
   making the simple kernel change required to enforce exclusive access to
   serial devices. (Well, perhaps not so simple when bidirectionality must
   also be a goal -- but then other OS's like VMS solved this problem
   decades ago.)

12. CONFIGURING UNIX WORKSTATIONS

   [ [338]Top ] [ [339]Contents ] [ [340]Next ] [ [341]Previous ]

   On desktop workstations that are used by only the user at the console
   keyboard, C-Kermit is always used in local mode. But as delivered,
   C-Kermit runs in remote mode by default. To put it in local mode at
   startup, you can put a SET LINE command in your .mykermrc.

   You can also build C-Kermit to start up in local mode by default. To do
   this, include the following in the CFLAGS in your makefile target:

-DDFTTY=\\\"/dev/ttyxx\\\"

   where ttyxx is the name of the device you will be using for
   communications. Presently there is no way of setting the default modem
   type at compile time, so use this option only for direct lines.

   C-Kermit does not work well on certain workstations if it is not run
   from within a terminal window. For example, you cannot start C-Kermit
   on a NeXT by launching it directly from NeXTstep. Similarly for Sun
   workstations in the Open Windows environment. Run Kermit in a terminal
   window.

13. BIZARRE BEHAVIOR AT RUNTIME

   [ [342]Top ] [ [343]Contents ] [ [344]Next ] [ [345]Previous ]

   See the "beware file",

   [346]ckubwr.txt, for hints about runtime misbehavior. This section
   lists some runtime problems that can be cured by rebuilding C-Kermit.

   The program starts, but there is no prompt, and certain operations
   don't work (you see error messages like "Kermit command error in
   background execution"). This is because Kermit thinks it is running in
   the background. See conbgt() in [347]ckutio.c. Try rebuilding Kermit
   with:

 -DPID_T=pid_t

   added to your CFLAGS. If that doesn't help, find out the actual data
   type for pids (look in types.h or similar file) and use it in place of
   "pid_t", for example:

 -DPID_T=short

   Unexplainable and inappropriate error messages ("Sockets not supported
   on this device", etc) have been traced in at least one case to a lack
   of agreement between the system header files and the actual kernel.
   This happened because the GNU C compiler (gcc) was being used. gcc
   wants to have ANSI-C-compliant header files, and so part of the
   installation procedure for gcc is (or was) to run a shell script called
   "fixincludes", which translates the system's header files into a
   separate set of headers that gcc likes. So far so good. Later, a new
   version of the operating system is installed and nobody remembers to
   run fixincludes again. From that point, any program compiled with gcc
   that makes use of header files (particularly ioctl.h) is very likely to
   misbehave. Solution: run fixincludes again, or use your system's
   regular C compiler, libraries, and header files instead of gcc.

14. CRASHES AND CORE DUMPS

   [ [348]Top ] [ [349]Contents ] [ [350]Next ] [ [351]Previous ]

   If C-Kermit constitently dumps core at the beginning of a file
   transfer, look in SHOW FEATURES for CKREALPATH. If found, rebuild with
   -DNOREALPATH and see if that fixes the problem (some UNIXes have
   realpath() but it doesn't work).

   Total failure of the Kermit program can occur because of bad memory
   references, bad system calls, or problems with dynamic memory
   allocation. First, try to reproduce the problem with debugging turned
   on: run Kermit with the -d command-line option (for example, "wermit
   -d") and then examine the resulting debug.log file. The last entry
   should be in the vicinity of the crash. In VMS, a crash automatically
   produces a "stack dump" which shows the routine where the crash occurs.
   In some versions of Unix, you can get a stack dump with "adb" -- just
   type "adb wermit core" and then give the command "$c", then Ctrl-D to
   quit (note: replace "wermit" by "kermit" or by the full pathname of the
   executable that crashed if it is not in the current directory). Or use
   gdb to get a backtrace, etc.

   In edit 186, one implementation, UNISYS 5000/95 built with "make
   sys5r3", has been reported to run out of memory very quickly (e.g.
   while executing a short initialization file that contains a SET DIAL
   DIRECTORY command). Debug logs show that malloc calls are failing,
   reason unknown. For this and any other implementation that gives error
   messages about "malloc failure" or "memory allocation failure", rebuild
   the program *without* the -DDYNAMIC CFLAGS definition, for example:

make sys5r3 KFLAGS=-UDYNAMIC

   As of edit 169, C-Kermit includes a malloc() debugging package which
   you may link with the Kermit program to catch runtime malloc errors.
   See the makefile entries for sunos41md and nextmd for examples of how
   to select malloc debugging. Once you have linked Kermit with the malloc
   debugger, it will halt with an informative message if a malloc-related
   error occurs and, if possible, dump core. For this reason,
   malloc-debugging versions of Kermit should be built without the "-s"
   link option (which removes symbols, preventing analysis of the core
   dump). You have several ways to track down the malloc error: Analyze
   the core dump with adb. Or reproduce the problem with "log debug" and
   then look at the code around the last debug.log entry. If you have gcc,
   build the program with "-g" added to CFLAGS and then debug it with gdb,
   e.g.

gdb wermit
break main
run
.. set other breakpoints or watchpoints
continue

   Watchpoints are especially useful for finding memory leaks, but they
   make the program run about a thousand times slower than usual, so don't
   set them until the last possible moment. When a watchpoint is hit, you
   can use the "where" command to find out which C-Kermit source statement
   triggered it.

   If you have the Pure Software Inc "Purify" product, see the sunos41cp
   makefile entry for an example of how to use it to debug C-Kermit.

15. SYSLOGGING

   [ [352]Top ] [ [353]Contents ] [ [354]Next ] [ [355]Previous ]

   "Syslogging" means recording selected information in the system log via
   the Unix syslog() facility, which is available in most Unix versions.
   Syslogging is not done unless C-Kermit is started with:

--syslog:n

   on the command-line, where n is a number greater than 0 to indicate the
   level of syslogging. See [356]Section 4.2 of the [357]IKSD
   Administrator's Guide for details.

   Obviously you can't depend on users to include --syslog:3 (or whatever)
   on the command line every time they start C-Kermit, so if you want
   certain kinds of records to be recorded in the system log, you can
   build C-Kermit with forced syslogging at the desired level; for
   example, to record logins and dialouts:

make linux KFLAGS=-DSYSLOGLEVEL=2

   Levels 2 and 3 are the most likely candidates for this treatment. Level
   2 forces logging of all successful dialout calls (e.g. for checking
   against or phone bills), and level 3 records all connections (SET LINE
   or SET HOST / TELNET / RLOGIN, etc) so you can see who is connecting
   out from your system, and to where, e.g. for security auditing.

   Level 2 and 3 records are equivalent to those in the connection log;
   see the [358]C-Kermit 7.0 Supplement) for a detailed description of the
   connection log.

16. BUILDING SECURE VERSIONS OF C-KERMIT 8.0

   [ [359]Top ] [ [360]Contents ] [ [361]Next ] [ [362]Previous ]

   C-Kermit 7.0 and later may be built with Kerberos(TM) and/or SRP(TM)
   (Secure Remote Password) and/or SSL/TLS security for strong
   authentication and encryption of Internet connections. These security
   methods require external libraries that, in their binary forms, are
   restricted from export by USA law. See the [363]Kermit Security
   Reference) for details. C-Kermit binaries themselves are likewise
   restricted; the C-Kermit binaries that are available for public
   download on the Internet are not allowed to contain the security
   options.

   Sample makefile entries are provided for Linux and many other operating
   systems. A list of secure makefile entries is included in the Makefile.
   Complete instructions on building C-Kermit 8.0 with MIT Kerberos;
   Secure Remote Password; and/or OpenSSL can be found in the [364]Kermit
   Security Reference.

   SSL/TLS and Kerberos builds are increasingly problematic with the
   "deprecation" of DES. There is code to detect the presence or absence
   of DES in the OpenSSL builds, but it doesn't always work because
   sometimes the SSL libraries are present but routines are missing from
   them.

     * First of all remember that if your SSL and/or Kerberos header files
       and libraries are not in the default place, you'll need to override
       the assumed paths. To find out what the default places are type
       "make show", e.g.:

[~/kermit] make show
prefix=/usr/local
srproot=/usr/local
sslroot=/usr/local
manroot=/usr/local
K4LIB=-L/usr/kerberos/lib
K4INC=-I/usr/kerberos/include
K5LIB=-L/usr/kerberos/lib
K5INC=-I/usr/kerberos/include
SRPLIB=-L/usr/local/lib
SRPINC=-I/usr/local/include
SSLLIB=-L/usr/local/ssl/lib
SSLINC=-I/usr/local/ssl/include
[~/kermit]

     * You can override any or all of these by putting assignments on the
       'make' command line; examples:

make linux+krb5 \
 "K5INC=-I/usr/include/" \
 "K5LIB=-L/usr/lib64/"

make solaris9g+ssl \
  "SSLLIB=-L/opt/openssl-0.9.8q/lib" \
  "SSLINC=-I/opt/openssl-0.9.8q/include"

       Or by setting and exporting environment variables prior to giving
       the 'make' command, as in this example in which (after Beta.01 was
       uploaded) C-Kermit was successfully linked with OpenSSL 1.0.0d,
       which was installed alongside OpenSSL 0.9.8r on the same computer.
       Note the use of the '-i' option instead of '-I' to force gcc to
       include the right header files (thanks to Nelson Beebe for this):

export PATH=/usr/bin:$PATH
export SSLINC=-isystem/usr/include
export "SSLLIB=-L/usr/lib -Wl,-rpath,/usr/lib"
make linux+ssl

       -i is explained in 'man gcc'; there is a change in what -I does
       that could have ramifications for many makefile targets, not just
       Kermit. And -Wl and -rpath are explained in 'man ld'; the idea is
       build a binary from which useful reports can be obtained with ldd.
     * Building with OpenSSL versions prior to 0.9.7 doesn't work, even
       though C-Kermit is designed to work with both the old and new
       versions. This could probably be fixed if anybody cares.
     * If a Kerberos or SSL build fails at link time because
       des_ecb3_encrypt, des_random_seed, and/or des_set_odd_parity come
       up missing, redo the build with -UCK_DES:

make netbsd+krb5+ssl \
 "K5INC=-I/usr/local/include" \
 "K5LIB=-L/usr/local/kerblib" KFLAGS=-UCK_DES

       I suppose all the SSL and Kerberos targets could be recoded to
       figure this out automatically (i.e. that DES is installed but with
       some entry points missing), but it wouldn't be pretty.
     * Different Kerberos and OpenSSL distributions can be installed with
       different options; certain libraries might be missing or named
       differently (for example, libgssapi vs libgssapi_krb5). Some, but
       not all, of the C-Kermit makefile targets have been fixed to take
       some of these variations into account by testing for them, most
       notably the linux ones, linux+ssl, linux+krb5, and linux+krb5+ssl.
       Probably every target that builds with OpenSSL or Kerberos needs
       the same treatment but I won't have time.
     * Why doesn't C-Kermit just use Autoconf? Mainly because the makefile
       is full of targets for platforms that don't have Autoconf or any
       other tool like it. (Another reason is that I've always preferred
       that Kermit have the least dependencies possible on external
       toolsets.) Perhaps certain targets could be converted to use them,
       especially Linux because there are so many variations among
       distributions and versions. Anybody who wants to make, say, an
       Autonf-based Linux target, be my guest, but bear in mind that one
       Linux target is supposed to work for all versions and distributions
       of Linux on all platforms. Well, one target for Linux by itself,
       another for Linux with OpenSSL, another for Linux with Kerberos 5,
       and another for Linux with Kerberos 5 and OpenSSL. Each of these is
       supposed to work on any Linux version with any version of
       Kerberos 5 or OpenSSL.

   Also note that Kerberos support is for the MIT version only, Heimdal
   and others are not supported (never have been). Of course anybody can
   pitch in and add or improve support for whatever they want.

17. INSTALLING C-KERMIT AS AN SSH SERVER SUBSYSTEM

   [ [365]Top ] [ [366]Contents ] [ [367]Previous ]

   This requires C-Kermit 8.0.206 or later and an SSH v2 server. If you
   list C-Kermit as a Subsystem in the SSH v2 server configuration file
   (as, for example, SFTP is listed), users can make SSH connections
   direct to a Kermit server as explained here:

[368]http://www.columbia.edu/kermit/skermit.html

   The name and location of the SSH server configuration file depends on
   your platform, which SSH product(s) you have, etc. C-Kermit itself must
   be referred to in this file as "kermit-sshsub". On the host, install
   the C-Kermit 8.0.211 binary in the normal way. Then, in the same
   directory as the C-Kermit binary, make a symbolic link:

ln -s kermit kermit-sshsub

   (Note: the "make install" makefile target does this for you.) Then in
   the sshd configuration file, add a line:

Subsystem  kermit   /some/path/kermit-sshsub

   (where /some/path is the fully specified directory where the symlink
   is.) This is similar to the line that sets up the SFTP susbsystem.
   Example:

Subsystem   sftp    /usr/local/libexec/sftp-server
Subsystem   kermit  /usr/local/bin/kermit-sshsub

   The mechanics might vary for other SSH servers; "man sshd" for details.
   The method shown here is used because the OpenSSH server does not
   permit the subsystem invocation to include command-line options.
   C-Kermit would have no way of knowing that it should enter Server mode
   if it were not called by a special name.

   [ [369]Top ] [ [370]Contents ] [ [371]C-Kermit Home ] [ [372]C-Kermit
   9.0 Overview ] [ [373]Kermit Home ]
     __________________________________________________________________


    C-Kermit 9.0 Unix Installation Instructions / The Kermit Project /
    Columbia University / 30 June 2011

References

   1. http://www.columbia.edu/
   2. mailto:kermit@columbia.edu
   3. http://www.columbia.edu/kermit/index.html
   4. http://www.columbia.edu/kermit/k95.html
   5. http://www.columbia.edu/kermit/ckermit.html
   6. http://www.columbia.edu/kermit/ckscripts.html
   7. http://www.columbia.edu/kermit/current.html
   8. http://www.columbia.edu/kermit/whatsnew.html
   9. http://www.columbia.edu/kermit/faq.html
  10. http://www.columbia.edu/kermit/support.html
  11. http://www.columbia.edu/kermit/ckuins.html#contents
  12. http://www.columbia.edu/kermit/ckermit.html
  13. http://www.columbia.edu/kermit/index.html
  14. http://www.columbia.edu/kermit/ckuins.html
  15. http://www.columbia.edu/kermit/ckuins.html#x0
  16. http://www.columbia.edu/kermit/ckuins.html#x1
  17. http://www.columbia.edu/kermit/ckuins.html#x2
  18. http://www.columbia.edu/kermit/ckuins.html#x3
  19. http://www.columbia.edu/kermit/ckuins.html#x4
  20. http://www.columbia.edu/kermit/ckuins.html#x5
  21. http://www.columbia.edu/kermit/ckuins.html#x6
  22. http://www.columbia.edu/kermit/ckuins.html#x7
  23. http://www.columbia.edu/kermit/ckuins.html#x8
  24. http://www.columbia.edu/kermit/ckuins.html#x9
  25. http://www.columbia.edu/kermit/ckuins.html#x10
  26. http://www.columbia.edu/kermit/ckuins.html#x11
  27. http://www.columbia.edu/kermit/ckuins.html#x12
  28. http://www.columbia.edu/kermit/ckuins.html#x13
  29. http://www.columbia.edu/kermit/ckuins.html#x14
  30. http://www.columbia.edu/kermit/ckuins.html#x15
  31. http://www.columbia.edu/kermit/ckuins.html#x16
  32. http://www.columbia.edu/kermit/ckuins.html#x17
  33. http://www.columbia.edu/kermit/ckuins.html#top
  34. http://www.columbia.edu/kermit/ckuins.html#contents
  35. http://www.columbia.edu/kermit/ckuins.html#x1
  36. http://www.columbia.edu/kermit/ckccfg.html
  37. http://www.columbia.edu/kermit/ckcbwr.html
  38. http://www.columbia.edu/kermit/ckubwr.html
  39. http://www.columbia.edu/kermit/ckcplm.html
  40. http://www.columbia.edu/kermit/ckuins.html#x2
  41. http://www.columbia.edu/kermit/ckuins.html#x3
  42. http://www.columbia.edu/kermit/ckuins.html#x4
  43. http://www.columbia.edu/kermit/ckuins.html#top
  44. http://www.columbia.edu/kermit/ckuins.html#contents
  45. http://www.columbia.edu/kermit/ckuins.html#x2
  46. http://www.columbia.edu/kermit/ckuins.html#x0
  47. ftp://www.columbia.edu/kermit/archives/cku211.tar.Z
  48. ftp://www.columbia.edu/kermit/archives/cku211.tar.gz
  49. http://kermit.columbia.edu/ftp/archives/cku211.tar.Z
  50. http://kermit.columbia.edu/ftp/archives/cku211.tar.gz
  51. ftp://www.columbia.edu/kermit/archives/cku211.tar
  52. http://kermit.columbia.edu/ftp/archives/cku211.tar
  53. http://www.columbia.edu/kermit/ckuins.html#x7
  54. http://www.columbia.edu/kermit/ckuins.html#x5
  55. http://www.columbia.edu/kermit/ckuins.html#x5
  56. http://www.columbia.edu/kermit/ckuins.html#x16
  57. http://www.columbia.edu/kermit/ckuins.html#top
  58. http://www.columbia.edu/kermit/ckuins.html#contents
  59. http://www.columbia.edu/kermit/ckuins.html#x3
  60. http://www.columbia.edu/kermit/ckuins.html#x1
  61. http://www.columbia.edu/kermit/ckuins.html#x5
  62. http://www.columbia.edu/kermit/ckuins.html#X10
  63. http://www.columbia.edu/kermit/ckuins.html#x11
  64. http://www.columbia.edu/kermit/ckuins.html#x10
  65. http://www.columbia.edu/kermit/ckuins.html#x3
  66. http://www.columbia.edu/kermit/ck80packages.html
  67. http://www.columbia.edu/kermit/ckuins.html#x10
  68. http://www.columbia.edu/kermit/ckuins.html#top
  69. http://www.columbia.edu/kermit/ckuins.html#contents
  70. http://www.columbia.edu/kermit/ckuins.html#x4
  71. http://www.columbia.edu/kermit/ckuins.html#x2
  72. ftp://www.columbia.edu/kermit/bin/
  73. http://www.columbia.edu/kermit/ck80binaries.html
  74. http://www.columbia.edu/kermit/ckuins.html#x7
  75. http://www.columbia.edu/kermit/ckuins.html#build
  76. http://www.columbia.edu/kermit/ckuins.html#x5
  77. http://www.columbia.edu/kermit/ckuins.html#x4
  78. http://www.columbia.edu/kermit/ckfaq.html#version
  79. http://www.columbia.edu/kermit/ckuins.html#x4
  80. mailto:kermit@columbia.edu
  81. http://www.columbia.edu/kermit/ckuins.html#top
  82. http://www.columbia.edu/kermit/ckuins.html#contents
  83. http://www.columbia.edu/kermit/ckuins.html#x5
  84. http://www.columbia.edu/kermit/ckuins.html#x3
  85. http://www.columbia.edu/kermit/ckuins.html#x8
  86. http://www.columbia.edu/kermit/ckuins.html#x9
  87. ftp://kermit.columbia.edu/kermit/c-kermit/makefile
  88. ftp://kermit.columbia.edu/kermit/c-kermit/ckpker.mk
  89. ftp://kermit.columbia.edu/kermit/c-kermit/ckubsd.mak
  90. http://www.columbia.edu/kermit/ckuins.html#x5
  91. mailto:kermit-support@columbia.edu
  92. ftp://kermit.columbia.edu/kermit/c-kermit/makefile
  93. http://www.columbia.edu/kermit/ckuins.html#x7
  94. mailto:kermit-support@columbia.edu
  95. ftp://kermit.columbia.edu/kermit/c-kermit/makefile
  96. http://www.columbia.edu/kermit/ckuins.html#x5.4
  97. http://www.columbia.edu/kermit/ckuins.html#x10
  98. http://www.columbia.edu/kermit/ckuins.html#x11
  99. http://www.columbia.edu/kermit/ckuins.html#x5
 100. http://www.columbia.edu/kermit/iksd.html
 101. http://www.columbia.edu/kermit/ckuins.html#top
 102. http://www.columbia.edu/kermit/ckuins.html#contents
 103. http://www.columbia.edu/kermit/ckuins.html#x4.1
 104. http://www.columbia.edu/kermit/ckccfg.html
 105. http://www.columbia.edu/kermit/ckuins.html#x4.1
 106. http://www.columbia.edu/kermit/ckuins.html#x4.2
 107. http://www.columbia.edu/kermit/ckuins.html#x4.3
 108. http://www.columbia.edu/kermit/ckuins.html#x4.4
 109. http://www.columbia.edu/kermit/ckuins.html#x4.5
 110. http://www.columbia.edu/kermit/ckccfg.html
 111. http://www.columbia.edu/kermit/ckccfg.html#x8
 112. http://www.columbia.edu/kermit/iksd.html
 113. http://www.columbia.edu/kermit/iksd.html
 114. ftp://kermit.columbia.edu/kermit/c-kermit/ckufio.c
 115. ftp://kermit.columbia.edu/kermit/c-kermit/ckufio.c
 116. mailto:kermit-support@columbia.edu
 117. ftp://kermit.columbia.edu/kermit/c-kermit/ckcmai.c
 118. http://www.columbia.edu/kermit/ckuins.html#x15
 119. ftp://kermit.columbia.edu/kermit/c-kermit/ckutio.c
 120. ftp://kermit.columbia.edu/kermit/c-kermit/ckufio.c
 121. ftp://kermit.columbia.edu/kermit/c-kermit/ckutio.c
 122. ftp://kermit.columbia.edu/kermit/c-kermit/ckufio.c
 123. ftp://kermit.columbia.edu/kermit/c-kermit/ckcnet.c
 124. ftp://kermit.columbia.edu/kermit/c-kermit/ckcnet.c
 125. ftp://kermit.columbia.edu/kermit/c-kermit/ckutio.c
 126. ftp://kermit.columbia.edu/kermit/c-kermit/ckcuni.c
 127. mailto:kermit-support@columbia.edu
 128. http://www.columbia.edu/kermit/ckuins.html#top
 129. http://www.columbia.edu/kermit/ckuins.html#contents
 130. http://www.columbia.edu/kermit/ckuins.html#x4
 131. http://www.columbia.edu/kermit/ckuins.html#x4.2
 132. http://www.columbia.edu/kermit/ckuins.html#x4.0
 133. ftp://kermit.columbia.edu/kermit/c-kermit/makefile
 134. ftp://kermit.columbia.edu/kermit/c-kermit/ckubwr.txt
 135. http://www.columbia.edu/kermit/ckubwr.html
 136. ftp://kermit.columbia.edu/kermit/c-kermit/ckwart.c
 137. ftp://kermit.columbia.edu/kermit/c-kermit/ckcpro.w
 138. ftp://kermit.columbia.edu/kermit/c-kermit/ckcpro.c
 139. http://www.columbia.edu/kermit/ckuins.html#top
 140. http://www.columbia.edu/kermit/ckuins.html#contents
 141. http://www.columbia.edu/kermit/ckuins.html#x4
 142. http://www.columbia.edu/kermit/ckuins.html#x4.3
 143. http://www.columbia.edu/kermit/ckuins.html#x4.1
 144. http://www.columbia.edu/kermit/ckuins.html#x5
 145. http://www.columbia.edu/kermit/ckuins.html#top
 146. http://www.columbia.edu/kermit/ckuins.html#contents
 147. http://www.columbia.edu/kermit/ckuins.html#x4
 148. http://www.columbia.edu/kermit/ckuins.html#x4.4
 149. http://www.columbia.edu/kermit/ckuins.html#x4.2
 150. http://www.columbia.edu/kermit/ckuins.html#top
 151. http://www.columbia.edu/kermit/ckuins.html#contents
 152. http://www.columbia.edu/kermit/ckuins.html#x4
 153. http://www.columbia.edu/kermit/ckuins.html#x4.5
 154. http://www.columbia.edu/kermit/ckuins.html#x4.3
 155. ftp://kermit.columbia.edu/kermit/c-kermit/ckpker.mk
 156. http://www.columbia.edu/kermit/ckuins.html#top
 157. http://www.columbia.edu/kermit/ckuins.html#contents
 158. http://www.columbia.edu/kermit/ckuins.html#x4
 159. http://www.columbia.edu/kermit/ckuins.html#x4.4
 160. ftp://kermit.columbia.edu/kermit/c-kermit/makefile
 161. ftp://kermit.columbia.edu/kermit/c-kermit/makefile
 162. ftp://kermit.columbia.edu/kermit/c-kermit/ckcpro.w
 163. http://www.columbia.edu/kermit/ckuins.html#top
 164. http://www.columbia.edu/kermit/ckuins.html#contents
 165. http://www.columbia.edu/kermit/ckuins.html#x6
 166. http://www.columbia.edu/kermit/ckuins.html#x4
 167. http://www.columbia.edu/kermit/ckuins.html#x5.1
 168. http://www.columbia.edu/kermit/ckuins.html#x5.2
 169. http://www.columbia.edu/kermit/ckuins.html#x5.3
 170. http://www.columbia.edu/kermit/ckuins.html#x5.4
 171. http://www.columbia.edu/kermit/
 172. http://www.columbia.edu/kermit/ckuins.html#x5.4
 173. http://www.columbia.edu/kermit/ckuins.html#x5.3
 174. ftp://kermit.columbia.edu/kermit/c-kermit/COPYING.TXT
 175. ftp://kermit.columbia.edu/kermit/c-kermit/ckermit.ini
 176. http://www.columbia.edu/kermit/ckuins.html#x5.1
 177. ftp://kermit.columbia.edu/kermit/c-kermit/ckermod.ini
 178. ftp://kermit.columbia.edu/kermit/c-kermit/ckermit70.txt
 179. http://www.columbia.edu/kermit/ck60manual.html
 180. http://www.columbia.edu/kermit/ckermit70.html
 181. ftp://kermit.columbia.edu/kermit/c-kermit/ckermit80.txt
 182. http://www.columbia.edu/kermit/ck60manual.html
 183. http://www.columbia.edu/kermit/ckermit80.html
 184. ftp://kermit.columbia.edu/kermit/c-kermit/ckcbwr.txt
 185. http://www.columbia.edu/kermit/ckcbwr.html
 186. ftp://kermit.columbia.edu/kermit/c-kermit/ckubwr.txt
 187. http://www.columbia.edu/kermit/ckubwr.html
 188. ftp://kermit.columbia.edu/kermit/c-kermit/ckuins.txt
 189. http://www.columbia.edu/kermit/ckuins.html
 190. ftp://kermit.columbia.edu/kermit/c-kermit/ckccfg.txt
 191. http://www.columbia.edu/kermit/ckccfg.html
 192. ftp://kermit.columbia.edu/kermit/c-kermit/ckcplm.txt
 193. http://www.columbia.edu/kermit/ckcplm.html
 194. ftp://kermit.columbia.edu/kermit/c-kermit/ca_certs.pem
 195. http://www.columbia.edu/kermit/ckuins.html#x16"
 196. ftp://kermit.columbia.edu/kermit/c-kermit/makefile
 197. http://www.columbia.edu/kermit/ckuins.html#x?
 198. http://www.columbia.edu/kermit/ckuins.html#x11
 199. http://www.columbia.edu/kermit/ckuins.html#x5.2
 200. http://www.columbia.edu/kermit/ckermit.html#download
 201. http://www.columbia.edu/kermit/ck80binaries.html
 202. http://www.columbia.edu/kermit/ckermit.html#download
 203. http://www.columbia.edu/kermit/ckuins.html#top
 204. http://www.columbia.edu/kermit/ckuins.html#contents
 205. http://www.columbia.edu/kermit/ckuins.html#x7
 206. http://www.columbia.edu/kermit/ckuins.html#x5
 207. http://www.columbia.edu/kermit/ckuins.html#top
 208. http://www.columbia.edu/kermit/ckuins.html#contents
 209. http://www.columbia.edu/kermit/ckuins.html#x8
 210. http://www.columbia.edu/kermit/ckuins.html#x6
 211. ftp://kermit.columbia.edu/kermit/c-kermit/ckutio.c
 212. ftp://kermit.columbia.edu/kermit/c-kermit/ckutio.c
 213. http://www.columbia.edu/kermit/ckuins.html#x4.0
 214. ftp://kermit.columbia.edu/kermit/c-kermit/ckcdeb.h
 215. ftp://kermit.columbia.edu/kermit/c-kermit/ckufio.c
 216. ftp://kermit.columbia.edu/kermit/c-kermit/ckufio.c
 217. ftp://kermit.columbia.edu/kermit/c-kermit/ckutio.c
 218. http://www.columbia.edu/kermit/ckuins.html#x10
 219. http://www.columbia.edu/kermit/ckccfg.html#x2
 220. http://www.columbia.edu/kermit/ckccfg.html
 221. http://www.columbia.edu/kermit/ckuins.html#x4
 222. http://www.columbia.edu/kermit/ckuins.html#x10
 223. ftp://kermit.columbia.edu/kermit/c-kermit/ckutio.c
 224. ftp://kermit.columbia.edu/kermit/c-kermit/ckutio.c
 225. ftp://kermit.columbia.edu/kermit/c-kermit/ckutio.c
 226. http://www.columbia.edu/kermit/ckuins.html#x9.4
 227. mailto:kermit-support@columbia.edu
 228. http://www.columbia.edu/kermit/ckuins.html#top
 229. http://www.columbia.edu/kermit/ckuins.html#contents
 230. http://www.columbia.edu/kermit/ckuins.html#x9
 231. http://www.columbia.edu/kermit/ckuins.html#x7
 232. http://www.columbia.edu/kermit/ckccfg.html
 233. http://www.columbia.edu/kermit/ckccfg.html
 234. http://www.columbia.edu/kermit/ckuins.html#top
 235. http://www.columbia.edu/kermit/ckuins.html#contents
 236. http://www.columbia.edu/kermit/ckuins.html#x10
 237. http://www.columbia.edu/kermit/ckuins.html#x8
 238. http://www.columbia.edu/kermit/ckuins.html#x9.1
 239. http://www.columbia.edu/kermit/ckuins.html#x9.1.1
 240. http://www.columbia.edu/kermit/ckuins.html#x9.1.2
 241. http://www.columbia.edu/kermit/ckuins.html#x9.1.3
 242. http://www.columbia.edu/kermit/ckuins.html#x9.2
 243. http://www.columbia.edu/kermit/ckuins.html#x9.3
 244. http://www.columbia.edu/kermit/ckuins.html#x9.4
 245. http://www.columbia.edu/kermit/ckuins.html#x9.5
 246. http://www.columbia.edu/kermit/ckuins.html#x9.6
 247. http://www.columbia.edu/kermit/ckuins.html#x9.7
 248. http://www.columbia.edu/kermit/ckuins.html#x9.8
 249. http://www.columbia.edu/kermit/ckuins.html#x9.9
 250. ftp://kermit.columbia.edu/kermit/c-kermit/ckutio.c
 251. http://www.columbia.edu/kermit/ckuins.html#top
 252. http://www.columbia.edu/kermit/ckuins.html#x9
 253. http://www.columbia.edu/kermit/ckuins.html#contents
 254. http://www.columbia.edu/kermit/ckuins.html#x9.2
 255. http://www.columbia.edu/kermit/ckuins.html#x9.1.1
 256. http://www.columbia.edu/kermit/ckuins.html#x9.1.2
 257. http://www.columbia.edu/kermit/ckuins.html#x9.1.3
 258. http://www.columbia.edu/kermit/ckuins.html#top
 259. http://www.columbia.edu/kermit/ckuins.html#contents
 260. http://www.columbia.edu/kermit/ckuins.html#x9
 261. http://www.columbia.edu/kermit/ckuins.html#x9.1
 262. http://www.columbia.edu/kermit/ckuins.html#x9.1.3
 263. http://www.columbia.edu/kermit/ckuins.html#x9.1.1
 264. http://www.columbia.edu/kermit/ckuins.html#top
 265. http://www.columbia.edu/kermit/ckuins.html#contents
 266. http://www.columbia.edu/kermit/ckuins.html#x9
 267. http://www.columbia.edu/kermit/ckuins.html#x9.1
 268. http://www.columbia.edu/kermit/ckuins.html#x9.2
 269. http://www.columbia.edu/kermit/ckuins.html#x9.1.2
 270. http://www.opengroup.org/onlinepubs/007904975/
 271. http://www.columbia.edu/kermit/ckuins.html#x9.1.1
 272. http://www.columbia.edu/kermit/ckuins.html#top
 273. http://www.columbia.edu/kermit/ckuins.html#contents
 274. http://www.columbia.edu/kermit/ckuins.html#x9
 275. http://www.columbia.edu/kermit/ckuins.html#x9.1
 276. http://www.columbia.edu/kermit/ckuins.html#x9.3
 277. http://www.columbia.edu/kermit/ckuins.html#x9.1
 278. http://www.columbia.edu/kermit/ckuins.html#top
 279. http://www.columbia.edu/kermit/ckuins.html#contents
 280. http://www.columbia.edu/kermit/ckuins.html#x9
 281. http://www.columbia.edu/kermit/ckuins.html#x9.4
 282. http://www.columbia.edu/kermit/ckuins.html#x9.2
 283. ftp://kermit.columbia.edu/kermit/c-kermit/ckufio.c
 284. ftp://kermit.columbia.edu/kermit/c-kermit/ckutio.c
 285. ftp://kermit.columbia.edu/kermit/c-kermit/ckufio.c
 286. http://www.columbia.edu/kermit/ckuins.html#top
 287. http://www.columbia.edu/kermit/ckuins.html#contents
 288. http://www.columbia.edu/kermit/ckuins.html#x9
 289. http://www.columbia.edu/kermit/ckuins.html#x9.5
 290. http://www.columbia.edu/kermit/ckuins.html#x9.3
 291. http://www.columbia.edu/kermit/cable.html
 292. ftp://kermit.columbia.edu/kermit/c-kermit/ckutio.c
 293. ftp://kermit.columbia.edu/kermit/c-kermit/ckcdeb.h
 294. http://www.columbia.edu/kermit/ckuins.html#top
 295. http://www.columbia.edu/kermit/ckuins.html#contents
 296. http://www.columbia.edu/kermit/ckuins.html#x9
 297. http://www.columbia.edu/kermit/ckuins.html#x9.6
 298. http://www.columbia.edu/kermit/ckuins.html#x9.4
 299. ftp://kermit.columbia.edu/kermit/c-kermit/ckcdeb.h
 300. ftp://kermit.columbia.edu/kermit/c-kermit/ckuus3.c
 301. ftp://kermit.columbia.edu/kermit/c-kermit/ckutio.c
 302. http://www.columbia.edu/kermit/ckuins.html#top
 303. http://www.columbia.edu/kermit/ckuins.html#contents
 304. http://www.columbia.edu/kermit/ckuins.html#x9
 305. http://www.columbia.edu/kermit/ckuins.html#x9.7
 306. http://www.columbia.edu/kermit/ckuins.html#x9.5
 307. http://www.columbia.edu/kermit/ckuins.html#top
 308. http://www.columbia.edu/kermit/ckuins.html#contents
 309. http://www.columbia.edu/kermit/ckuins.html#x9
 310. http://www.columbia.edu/kermit/ckuins.html#x9.8
 311. http://www.columbia.edu/kermit/ckuins.html#x9.6
 312. http://www.columbia.edu/kermit/ckuins.html#top
 313. http://www.columbia.edu/kermit/ckuins.html#contents
 314. http://www.columbia.edu/kermit/ckuins.html#x9
 315. http://www.columbia.edu/kermit/ckuins.html#x9.9
 316. http://www.columbia.edu/kermit/ckuins.html#x9.7
 317. ftp://kermit.columbia.edu/kermit/c-kermit/ckutio.c
 318. ftp://kermit.columbia.edu/kermit/c-kermit/ckutio.c
 319. ftp://kermit.columbia.edu/kermit/c-kermit/ckcdeb.h
 320. ftp://kermit.columbia.edu/kermit/c-kermit/ckufio.c
 321. http://www.columbia.edu/kermit/ckuins.html#top
 322. http://www.columbia.edu/kermit/ckuins.html#contents
 323. http://www.columbia.edu/kermit/ckuins.html#x9
 324. http://www.columbia.edu/kermit/ckuins.html#x10
 325. http://www.columbia.edu/kermit/ckuins.html#x9.8
 326. http://www.columbia.edu/kermit/ckuins.html#top
 327. http://www.columbia.edu/kermit/ckuins.html#contents
 328. http://www.columbia.edu/kermit/ckuins.html#x11
 329. http://www.columbia.edu/kermit/ckuins.html#x9
 330. ftp://kermit.columbia.edu/kermit/c-kermit/ckutio.c
 331. http://www.columbia.edu/kermit/ckuins.html#x11
 332. http://www.columbia.edu/kermit/ckuins.html#top
 333. http://www.columbia.edu/kermit/ckuins.html#contents
 334. http://www.columbia.edu/kermit/ckuins.html#x12
 335. http://www.columbia.edu/kermit/ckuins.html#x10
 336. ftp://kermit.columbia.edu/kermit/c-kermit/ckutio.c
 337. ftp://kermit.columbia.edu/kermit/c-kermit/ckufio.c
 338. http://www.columbia.edu/kermit/ckuins.html#top
 339. http://www.columbia.edu/kermit/ckuins.html#contents
 340. http://www.columbia.edu/kermit/ckuins.html#x13
 341. http://www.columbia.edu/kermit/ckuins.html#x11
 342. http://www.columbia.edu/kermit/ckuins.html#top
 343. http://www.columbia.edu/kermit/ckuins.html#contents
 344. http://www.columbia.edu/kermit/ckuins.html#x14
 345. http://www.columbia.edu/kermit/ckuins.html#x12
 346. ftp://kermit.columbia.edu/kermit/c-kermit/ckubwr.txt
 347. ftp://kermit.columbia.edu/kermit/c-kermit/ckutio.c
 348. http://www.columbia.edu/kermit/ckuins.html#top
 349. http://www.columbia.edu/kermit/ckuins.html#contents
 350. http://www.columbia.edu/kermit/ckuins.html#x15
 351. http://www.columbia.edu/kermit/ckuins.html#x13
 352. http://www.columbia.edu/kermit/ckuins.html#top
 353. http://www.columbia.edu/kermit/ckuins.html#contents
 354. http://www.columbia.edu/kermit/ckuins.html#x16
 355. http://www.columbia.edu/kermit/ckuins.html#x14
 356. http://www.columbia.edu/kermit/uiksd.html#x4.2
 357. http://www.columbia.edu/kermit/uiksd.html
 358. http://www.columbia.edu/kermit/ckermit2.html
 359. http://www.columbia.edu/kermit/ckuins.html#top
 360. http://www.columbia.edu/kermit/ckuins.html#contents
 361. http://www.columbia.edu/kermit/ckuins.html#x17
 362. http://www.columbia.edu/kermit/ckuins.html#x15
 363. http://www.columbia.edu/kermit/security.html
 364. http://www.columbia.edu/kermit/security80.html
 365. http://www.columbia.edu/kermit/ckuins.html#top
 366. http://www.columbia.edu/kermit/ckuins.html#contents
 367. http://www.columbia.edu/kermit/ckuins.html#x16
 368. http://www.columbia.edu/kermit/skermit.html
 369. http://www.columbia.edu/kermit/ckuins.html#top
 370. http://www.columbia.edu/kermit/ckuins.html#contents
 371. http://www.columbia.edu/kermit/ckermit.html
 372. http://www.columbia.edu/kermit/ck90updates.html
 373. http://www.columbia.edu/kermit/index.html