+++ /dev/null
-
-C-Kermit 8.0 Unix Installation Instructions
-
- [ [1]Contents ] [ [2]C-Kermit ] [ [3]Kermit Home ]
-
- Frank da Cruz
- The Kermit Project
- Columbia University
-
- As of C-Kermit version: 8.0.211, 10 April 2004
- This file last updated: Tue Apr 13 10:14:33 2004 (New York City
- time)
-
- IF YOU ARE READING A PLAIN-TEXT version of this document, note that
- this file is a plain-text dump of a Web page. You can visit the
- original (and possibly more up-to-date) Web page here:
-
-[4]http://www.columbia.edu/kermit/ckuins.html
- __________________________________________________________________________
-
-CONTENTS
-
- [5]OVERVIEW
-
- 1. [6]INTERNET QUICK START
- 2. [7]INSTALLING FROM PACKAGES
- 3. [8]INSTALLING PREBUILT BINARIES
- 4. [9]BUILDING FROM SOURCE CODE
- 5. [10]INSTALLING THE KERMIT FILES
- 6. [11]INSTALLING UNIX C-KERMIT FROM DOS-FORMAT DISKETTES
- 7. [12]CHECKING THE RESULTS
- 8. [13]REDUCING THE SIZE OF THE EXECUTABLE PROGRAM IMAGE
- 9. [14]UNIX VERSIONS
- 10. [15]DIALING OUT AND COORDINATING WITH UUCP
- 11. [16]RUNNING UNIX C-KERMIT SETUID OR SETGID
- 12. [17]CONFIGURING UNIX WORKSTATIONS
- 13. [18]BIZARRE BEHAVIOR AT RUNTIME
- 14. [19]CRASHES AND CORE DUMPS
- 15. [20]SYSLOGGING
- 16. [21]BUILDING SECURE VERSIONS OF C-KERMIT 8.0
- 17. [22]INSTALLING C-KERMIT AS AN SSH SERVER SUBSYSTEM
- __________________________________________________________________________
-
-OVERVIEW
-
- [ [23]Top ] [ [24]Contents ] [ [25]Next ]
-
- WARNING: This document contains notes that have been accumulating
- since the early 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 [26]Configurations
- Options document. For troubleshooting after installation, see the
- [27]General Hints and Tips and [28]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 [29]C-Kermit Program Logic Manual
-
- You may install C-Kermit:
-
- * From an "[30]install package", if one is available.
- * As a [31]prebuilt binary, if available, plus accompanying text
- files.
- * By building from [32]source code.
- __________________________________________________________________________
-
-1. INTERNET QUICK START
-
- [ [33]Top ] [ [34]Contents ] [ [35]Next ] [ [36]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:
- [37]ftp://kermit.columbia.edu/kermit/archives/cku211.tar.Z
- (compress format) or
- [38]ftp://kermit.columbia.edu/kermit/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:
- [39]ftp://kermit.columbia.edu/kermit/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 [40]try it out to make sure it
- works. Then read [41]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 [42]Sections 5 and [43]16.
- __________________________________________________________________________
-
-2. INSTALLING FROM PACKAGES
-
- [ [44]Top ] [ [45]Contents ] [ [46]Next ] [ [47]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 [48]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 [49]Sections 10 and [50]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 [51]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."
- 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 ([52]next section) from other sites are
- likely to have library mismatches. [53]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 [54]Section
- 10 for details.
- __________________________________________________________________________
-
-3. INSTALLING PREBUILT BINARIES
-
- [ [55]Top ] [ [56]Contents ] [ [57]Next ] [ [58]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 [59]kermit/bin area (with names starting
- with "ck"), also accessible on the [60]C-Kermit website. To install a
- prebuilt binary:
-
- a. Rename the binary to "wermit".
- b. Make sure it works; some tests are suggested in [61]Section 7.
- c. Follow steps (b) through (e) in [62]Section 4.
- d. Install related files as described in [63]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 [64]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 usually safe to run
- a binary built on (or for) an older OS release on a newer one.
-
- Therefore, it is better to build your own binary from source code
- ([65]next section) if you can. But since it is increasingly for Unix
- systems (not to mention VMS and other OS's) to be delivered without C
- compilers, it is often impractical. In such cases, try the most
- appropriate prebuilt binary or binaries, and if none of them work,
- [66]contact us and we'll see what we can do to help.
- __________________________________________________________________________
-
-4. BUILDING FROM SOURCE CODE
-
- [ [67]Top ] [ [68]Contents ] [ [69]Next ] [ [70]Previous ]
-
- Also see: [71]Section 8 and [72]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, and the linker. It
- does not use any 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 [73]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 [74]Plan 9 and [75]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 ([76]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 [77]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:
-
-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.
-
- 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 [78]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 [79]Section 7 for
- suggestions). If it's OK, proceed; otherwise [80]notify us.
-
- NOTE: steps (c) through (e) can be accomplished using the
- [81]makefile 'install' target as described in [82]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
- [83]Sections 10 and [84]11 for details).
- d. Install the man page, ckuker.nr, with your other man pages.
- e. Install the accompanying text files (see [85]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 [86]IKSD Administrator's Guide.
- ________________________________________________________________________
-
- 4.0. Special Considerations for C-Kermit 8.0
-
- [ [87]Top ] [ [88]Contents ] [ [89]Next ]
-
- Also see: [90]C-Kermit Configuration Options
-
- SECTION CONTENTS
-
-4.1. [91]The Unix Makefile
-4.2. [92]The C-Kermit Initialization File
-4.3. [93]The 2.x BSD Makefile
-4.4. [94]The Plan 9 Makefile
-4.5. [95]Makefile Failures
-
- (Also see the [96]Configurations Options document, [97]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 [98]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 [99]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 [100]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 Plugable 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
- [101]ckufio.c, and [102]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 [103]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 [104]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, [105]ckutio.c or [106]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 [107]ckutio.c or [108]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 [109]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 [110]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 [111]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 [112]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:
-
-[113]kermit-support@columbia.edu
- ________________________________________________________________________
-
- 4.1. The Unix Makefile
-
- [ [114]Top ] [ [115]Contents ] [ [116]Section Contents ] [ [117]Next ]
- [ [118]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 [119]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 [120]ckubwr.txt file ([121]CLICK HERE for the Web version).
-
- If you have trouble with building [122]ckwart.c, or running the
- resulting wart preprocessor program on [123]ckcpro.w:
-
- 1. Just "touch" the [124]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
-
- [ [125]Top ] [ [126]Contents ] [ [127]Section Contents ] [ [128]Next ]
- [ [129]Previous ]
-
- (This section is obsolete.) Read [130]Section 5 about the
- initialization file.
- ________________________________________________________________________
-
- 4.3. The 2.x BSD Makefile
-
- [ [131]Top ] [ [132]Contents ] [ [133]Section Contents ] [ [134]Next ]
- [ [135]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
-
- [ [136]Top ] [ [137]Contents ] [ [138]Section Contents ] [ [139]Next ]
- [ [140]Previous ]
-
- Use the separate makefile [141]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
-
- [ [142]Top ] [ [143]Contents ] [ [144]Section Contents ] [
- [145]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 [146]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 [147]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 [148]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
-
- [ [149]Top ] [ [150]Contents ] [ [151]Next ] [ [152]Previous ]
-
- SECTION CONTENTS
-
-5.1. [153]The C-Kermit Initialization File
-5.2. [154]Text Files
-5.3. [155]Installing the Kermit Files
-5.4. [156]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:
-
-[157]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 [158]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 [159]next section.
-
- [160]COPYING.TXT
- Copyright notice, permissions, and disclaimer.
-
- [161]ckermit.ini
- The standard initialization file, intended more for reference
- (in most cases) than actual use; see [162]Section 5.1.
-
- [163]ckermod.ini
- A sample customization file.
-
- [164]ckermit70.txt
- Supplement to [165]Using C-Kermit for version 7.0. Available on
- the Kermit website as:
- [166]http://www.columbia.edu/kermit/ckermit70.html
-
- [167]ckermit80.txt
- Supplement to [168]Using C-Kermit for version 8.0. Available on
- the Kermit website as:
- [169]http://www.columbia.edu/kermit/ckermit80.html
-
- [170]ckcbwr.txt
- The general C-Kermit hints and tips ("beware") file. Available
- on the Kermit website as:
- [171]http://www.columbia.edu/kermit/ckcbwr.html
-
- [172]ckubwr.txt
- The Unix-specific C-Kermit hints and tips file. Available on
- the Kermit website as:
- [173]http://www.columbia.edu/kermit/ckubwr.html
-
- [174]ckuins.txt
- Unix C-Kermit Installation Instructions (this file). Available
- on the Kermit website as:
- [175]http://www.columbia.edu/kermit/ckuins.html
-
- [176]ckccfg.txt
- C-Kermit compile-time configuration options. Available on the
- Kermit website as:
- [177]http://www.columbia.edu/kermit/ckccfg.html
-
- [178]ckcplm.txt
- The C-Kermit program logic manual. Available on the Kermit
- website as:
- [179]http://www.columbia.edu/kermit/ckcplm.html
-
- [180]ca_certs.pem
- Certificate Authority certificates for secure connections (see
- [181]Section 16).
-
- 5.3. Installing the Kermit Files
-
- There is an "install" target in the [182]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
- [183]Sections 10 and [184]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 [185]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 [186]complete C-Kermit archive and built
- C-Kermit from source; or:
- * You downloaded an [187]individual C-Kermit binary and the
- [188]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
-
- [ [189]Top ] [ [190]Contents ] [ [191]Next ] [ [192]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
-
- [ [193]Top ] [ [194]Contents ] [ [195]Next ] [ [196]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 [197]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 [198]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 [199]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
- [200]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 [201]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 [202]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 [203]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 [204]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 [205]Section 2) of the
- [206]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 [207]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 [208]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 [209]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
- [210]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 [211]ckutio.c and see if you can add the
- needed code (see the section on [212]HARDWARE FLOW CONTROL below).
- (And please [213]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
-
- [ [214]Top ] [ [215]Contents ] [ [216]Next ] [ [217]Previous ]
-
- Also see: [218]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 [219]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
-
- [ [220]Top ] [ [221]Contents ] [ [222]Next ] [ [223]Previous ]
-
- SECTION CONTENTS
-
-9.1 [224]Standards
- 9.1.1. [225]POSIX
- 9.1.2. [226]ANSI C
- 9.1.3. [227]Other Standards
-9.2. [228]Library Issues
-9.3. [229]Unix File System Peculiarities
-9.4. [230]Hardware Flow Control
-9.5. [231]Terminal Speeds
-9.6. [232]Millisecond Sleeps
-9.7. [233]Nondestructive Input Buffer Peeking
-9.8. [234]Other System-Dependent Features
-9.9. [235]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∓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 [236]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
-
- [ [237]Top ] [ [238]Section Contents ] [ [239]Contents ] [ [240]Next ]
-
- SUBSECTION CONTENTS
-
-9.1.1. [241]POSIX
-9.1.2. [242]ANSI C
-9.1.3. [243]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
-
- [ [244]Top ] [ [245]Contents ] [ [246]Section Contents ] [
- [247]Subsection Contents ] [ [248]Next ] [ [249]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
-
- [ [250]Top ] [ [251]Contents ] [ [252]Section Contents ] [
- [253]Subsection Contents ] [ [254]Next ] [ [255]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, [256]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
- [257]9.1.1).
- ________________________________________________________________________
-
- 9.2. Library Issues
-
- [ [258]Top ] [ [259]Contents ] [ [260]Section Contents ] [
- [261]Subsection Contents ] [ [262]Next ] [ [263]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
-
- [ [264]Top ] [ [265]Contents ] [ [266]Section Contents ] [ [267]Next ]
- [ [268]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 [269]ckufio.c and
- [270]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 [271]ckufio.c.
- ________________________________________________________________________
-
- 9.4. Hardware Flow Control
-
- [ [272]Top ] [ [273]Contents ] [ [274]Section Contents ] [ [275]Next ]
- [ [276]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 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 [277]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
- [278]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
-
- [ [279]Top ] [ [280]Contents ] [ [281]Section Contents ] [ [282]Next ]
- [ [283]Previous ]
-
- The allowable speeds for the SET SPEED command are defined in
- [284]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 [285]ckuus3.c, and the corresponding case to
- ttsspd() in [286]ckutio.c.
- ________________________________________________________________________
-
- 9.6. Millisecond Sleeps
-
- [ [287]Top ] [ [288]Contents ] [ [289]Section Contents ] [ [290]Next ]
- [ [291]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
-
- [ [292]Top ] [ [293]Contents ] [ [294]Section Contents ] [ [295]Next ]
- [ [296]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
-
- [ [297]Top ] [ [298]Contents ] [ [299]Section Contents ] [ [300]Next ]
- [ [301]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 [302]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 [303]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
- [304]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 [305]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
-
- [ [306]Top ] [ [307]Contents ] [ [308]Section Contents ] [ [309]Next ]
- [ [310]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
-
- [ [311]Top ] [ [312]Contents ] [ [313]Next ] [ [314]Previous ]
-
- NOTE: Red Hat Linux 7.2 and later include a new API that allows
- serial-port arbitration by non-setuid/gid programs. This API has
- not yet been added to C-Kermit. If C-Kermit is to be used for
- dialing out on Red Hat 7.2 or later, it must still be installed as
- described in this section and the next.
-
- The short version:
-
- 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 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, etc.
-
- Rather than change Unix to enforce exclusive access to serial devices
- such as ttys, Unix developers chose instead to use a "lock file". 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 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 [315]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, which is becoming increasingly popular, 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 [316]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
-
- [ [317]Top ] [ [318]Contents ] [ [319]Next ] [ [320]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
- [321]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 [322]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
-
- [ [323]Top ] [ [324]Contents ] [ [325]Next ] [ [326]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
-
- [ [327]Top ] [ [328]Contents ] [ [329]Next ] [ [330]Previous ]
-
- See the "beware file",
-
- [331]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 [332]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
-
- [ [333]Top ] [ [334]Contents ] [ [335]Next ] [ [336]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
-
- [ [337]Top ] [ [338]Contents ] [ [339]Next ] [ [340]Previous ]
-
- "Syslogging" means recording selected 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 [341]Section 4.2 of the [342]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,
- e.g.:
-
-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.
-
- Level 2 and 3 records are equivalent to those in the connection log;
- see the [343]C-Kermit 7.0 Supplement) for a detailed description of
- the connection log.
- __________________________________________________________________________
-
-16. BUILDING SECURE VERSIONS OF C-KERMIT 8.0
-
- [ [344]Top ] [ [345]Contents ] [ [346]Next ] [ [347]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 [348]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
- [349]Kermit Security Reference.
-
- C-Kermit 8.0 comes with a current list of Certificate Authority
- certificates, including one for the Kermit Project that can be used
- for authentication to Columbia's [350]Internet Kermit Service (IKSD).
- You can use C-Kermit 7.0 or later to access Columbia's IKSD securely
- by installing the Kermit Project certificate in
- /usr/local/ssl/cert.pem (or the appropriate location based upon the
- installation of OpenSSL on your system). You can find a copy of the
- certificates file at:
-
-[351]ftp://kermit.columbia.edu/kermit/c-kermit/ca_certs.pem
- __________________________________________________________________________
-
-17. INSTALLING C-KERMIT AS AN SSH SERVER SUBSYSTEM
-
- [ [352]Top ] [ [353]Contents ] [ [354]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:
-
-[355]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.
-
- [ [356]Top ] [ [357]Contents ] [ [358]C-Kermit Home ] [ [359]C-Kermit
- 8.0 Overview ] [ [360]Kermit Home ]
- _________________________________________________________________
-
-
- C-Kermit 8.0 Unix Installation Instructions / The Kermit Project /
- Columbia University / 10 April 2004
-
-References
-
- 1. http://www.columbia.edu/kermit/ckuins.html#contents
- 2. http://www.columbia.edu/kermit/ckermit.html
- 3. http://www.columbia.edu/kermit/index.html
- 4. http://www.columbia.edu/kermit/ckuins.html
- 5. http://www.columbia.edu/kermit/ckuins.html#x0
- 6. http://www.columbia.edu/kermit/ckuins.html#x1
- 7. http://www.columbia.edu/kermit/ckuins.html#x2
- 8. http://www.columbia.edu/kermit/ckuins.html#x3
- 9. http://www.columbia.edu/kermit/ckuins.html#x4
- 10. http://www.columbia.edu/kermit/ckuins.html#x5
- 11. http://www.columbia.edu/kermit/ckuins.html#x6
- 12. http://www.columbia.edu/kermit/ckuins.html#x7
- 13. http://www.columbia.edu/kermit/ckuins.html#x8
- 14. http://www.columbia.edu/kermit/ckuins.html#x9
- 15. http://www.columbia.edu/kermit/ckuins.html#x10
- 16. http://www.columbia.edu/kermit/ckuins.html#x11
- 17. http://www.columbia.edu/kermit/ckuins.html#x12
- 18. http://www.columbia.edu/kermit/ckuins.html#x13
- 19. http://www.columbia.edu/kermit/ckuins.html#x14
- 20. http://www.columbia.edu/kermit/ckuins.html#x15
- 21. http://www.columbia.edu/kermit/ckuins.html#x16
- 22. http://www.columbia.edu/kermit/ckuins.html#x16
- 23. http://www.columbia.edu/kermit/ckuins.html#top
- 24. http://www.columbia.edu/kermit/ckuins.html#contents
- 25. http://www.columbia.edu/kermit/ckuins.html#x1
- 26. http://www.columbia.edu/kermit/ckccfg.html
- 27. http://www.columbia.edu/kermit/ckcbwr.html
- 28. http://www.columbia.edu/kermit/ckubwr.html
- 29. http://www.columbia.edu/kermit/ckcplm.html
- 30. http://www.columbia.edu/kermit/ckuins.html#x2
- 31. http://www.columbia.edu/kermit/x3
- 32. http://www.columbia.edu/kermit/ckuins.html#x4
- 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#x2
- 36. http://www.columbia.edu/kermit/ckuins.html#x0
- 37. ftp://kermit.columbia.edu/kermit/archives/cku211.tar.Z
- 38. ftp://kermit.columbia.edu/kermit/archives/cku211.tar.gz
- 39. ftp://kermit.columbia.edu/kermit/archives/cku211.tar
- 40. http://www.columbia.edu/kermit/ckuins.html#x7
- 41. http://www.columbia.edu/kermit/ckuins.html#x5
- 42. http://www.columbia.edu/kermit/ckuins.html#x5
- 43. http://www.columbia.edu/kermit/ckuins.html#x16
- 44. http://www.columbia.edu/kermit/ckuins.html#top
- 45. http://www.columbia.edu/kermit/ckuins.html#contents
- 46. http://www.columbia.edu/kermit/ckuins.html#x3
- 47. http://www.columbia.edu/kermit/ckuins.html#x1
- 48. http://www.columbia.edu/kermit/ckuins.html#x5
- 49. http://www.columbia.edu/kermit/ckuins.html#X10
- 50. http://www.columbia.edu/kermit/ckuins.html#x11
- 51. http://www.columbia.edu/kermit/ckuins.html#x10
- 52. http://www.columbia.edu/kermit/ckuins.html#x3
- 53. http://www.columbia.edu/kermit/ck80packages.html
- 54. http://www.columbia.edu/kermit/ckuins.html#x10
- 55. http://www.columbia.edu/kermit/ckuins.html#top
- 56. http://www.columbia.edu/kermit/ckuins.html#contents
- 57. http://www.columbia.edu/kermit/ckuins.html#x4
- 58. http://www.columbia.edu/kermit/ckuins.html#x2
- 59. ftp://kermit.columbia.edu/kermit/bin/
- 60. http://www.columbia.edu/kermit/ck80binaries.html
- 61. http://www.columbia.edu/kermit/ckuins.html#x7
- 62. http://www.columbia.edu/kermit/ckuins.html#build
- 63. http://www.columbia.edu/kermit/ckuins.html#x5
- 64. http://www.columbia.edu/kermit/ckuins.html#x4
- 65. http://www.columbia.edu/kermit/ckuins.html#x4
- 66. mailto:kermit@columbia.edu
- 67. http://www.columbia.edu/kermit/ckuins.html#top
- 68. http://www.columbia.edu/kermit/ckuins.html#contents
- 69. http://www.columbia.edu/kermit/ckuins.html#x5
- 70. http://www.columbia.edu/kermit/ckuins.html#x3
- 71. http://www.columbia.edu/kermit/ckuins.html#x8
- 72. http://www.columbia.edu/kermit/ckuins.html#x9
- 73. ftp://kermit.columbia.edu/kermit/c-kermit/makefile
- 74. ftp://kermit.columbia.edu/kermit/c-kermit/ckpker.mk
- 75. ftp://kermit.columbia.edu/kermit/c-kermit/ckubsd.mak
- 76. http://www.columbia.edu/kermit/ckuins.html#x5
- 77. mailto:kermit-support@columbia.edu
- 78. ftp://kermit.columbia.edu/kermit/c-kermit/makefile
- 79. http://www.columbia.edu/kermit/ckuins.html#x7
- 80. mailto:kermit-support@columbia.edu
- 81. ftp://kermit.columbia.edu/kermit/c-kermit/makefile
- 82. http://www.columbia.edu/kermit/ckuins.html#x5.4
- 83. http://www.columbia.edu/kermit/ckuins.html#x10
- 84. http://www.columbia.edu/kermit/ckuins.html#x11
- 85. http://www.columbia.edu/kermit/ckuins.html#x5
- 86. http://www.columbia.edu/kermit/iksd.html
- 87. http://www.columbia.edu/kermit/ckuins.html#top
- 88. http://www.columbia.edu/kermit/ckuins.html#contents
- 89. http://www.columbia.edu/kermit/ckuins.html#x4.1
- 90. http://www.columbia.edu/kermit/ckccfg.html
- 91. http://www.columbia.edu/kermit/ckuins.html#x4.1
- 92. http://www.columbia.edu/kermit/ckuins.html#x4.2
- 93. http://www.columbia.edu/kermit/ckuins.html#x4.3
- 94. http://www.columbia.edu/kermit/ckuins.html#x4.4
- 95. http://www.columbia.edu/kermit/ckuins.html#x4.5
- 96. http://www.columbia.edu/kermit/ckccfg.html
- 97. http://www.columbia.edu/kermit/ckccfg.html#x8
- 98. http://www.columbia.edu/kermit/iksd.html
- 99. http://www.columbia.edu/kermit/iksd.html
- 100. ftp://kermit.columbia.edu/kermit/c-kermit/ckufio.c
- 101. ftp://kermit.columbia.edu/kermit/c-kermit/ckufio.c
- 102. mailto:kermit-support@columbia.edu
- 103. ftp://kermit.columbia.edu/kermit/c-kermit/ckcmai.c
- 104. http://www.columbia.edu/kermit/ckuins.html#x15
- 105. ftp://kermit.columbia.edu/kermit/c-kermit/ckutio.c
- 106. ftp://kermit.columbia.edu/kermit/c-kermit/ckufio.c
- 107. ftp://kermit.columbia.edu/kermit/c-kermit/ckutio.c
- 108. ftp://kermit.columbia.edu/kermit/c-kermit/ckufio.c
- 109. ftp://kermit.columbia.edu/kermit/c-kermit/ckcnet.c
- 110. ftp://kermit.columbia.edu/kermit/c-kermit/ckcnet.c
- 111. ftp://kermit.columbia.edu/kermit/c-kermit/ckutio.c
- 112. ftp://kermit.columbia.edu/kermit/c-kermit/ckcuni.c
- 113. mailto:kermit-support@columbia.edu
- 114. http://www.columbia.edu/kermit/ckuins.html#top
- 115. http://www.columbia.edu/kermit/ckuins.html#contents
- 116. http://www.columbia.edu/kermit/ckuins.html#x4
- 117. http://www.columbia.edu/kermit/ckuins.html#x4.2
- 118. http://www.columbia.edu/kermit/ckuins.html#x4.0
- 119. ftp://kermit.columbia.edu/kermit/c-kermit/makefile
- 120. ftp://kermit.columbia.edu/kermit/c-kermit/ckubwr.txt
- 121. http://www.columbia.edu/kermit/ckubwr.html
- 122. ftp://kermit.columbia.edu/kermit/c-kermit/ckwart.c
- 123. ftp://kermit.columbia.edu/kermit/c-kermit/ckcpro.w
- 124. ftp://kermit.columbia.edu/kermit/c-kermit/ckcpro.c
- 125. http://www.columbia.edu/kermit/ckuins.html#top
- 126. http://www.columbia.edu/kermit/ckuins.html#contents
- 127. http://www.columbia.edu/kermit/ckuins.html#x4
- 128. http://www.columbia.edu/kermit/ckuins.html#x4.3
- 129. http://www.columbia.edu/kermit/ckuins.html#x4.1
- 130. http://www.columbia.edu/kermit/ckuins.html#x5
- 131. http://www.columbia.edu/kermit/ckuins.html#top
- 132. http://www.columbia.edu/kermit/ckuins.html#contents
- 133. http://www.columbia.edu/kermit/ckuins.html#x4
- 134. http://www.columbia.edu/kermit/ckuins.html#x4.4
- 135. http://www.columbia.edu/kermit/ckuins.html#x4.2
- 136. http://www.columbia.edu/kermit/ckuins.html#top
- 137. http://www.columbia.edu/kermit/ckuins.html#contents
- 138. http://www.columbia.edu/kermit/ckuins.html#x4
- 139. http://www.columbia.edu/kermit/ckuins.html#x4.5
- 140. http://www.columbia.edu/kermit/ckuins.html#x4.3
- 141. ftp://kermit.columbia.edu/kermit/c-kermit/ckpker.mk
- 142. http://www.columbia.edu/kermit/ckuins.html#top
- 143. http://www.columbia.edu/kermit/ckuins.html#contents
- 144. http://www.columbia.edu/kermit/ckuins.html#x4
- 145. http://www.columbia.edu/kermit/ckuins.html#x4.4
- 146. ftp://kermit.columbia.edu/kermit/c-kermit/makefile
- 147. ftp://kermit.columbia.edu/kermit/c-kermit/makefile
- 148. ftp://kermit.columbia.edu/kermit/c-kermit/ckcpro.w
- 149. http://www.columbia.edu/kermit/ckuins.html#top
- 150. http://www.columbia.edu/kermit/ckuins.html#contents
- 151. http://www.columbia.edu/kermit/ckuins.html#x6
- 152. http://www.columbia.edu/kermit/ckuins.html#x4
- 153. http://www.columbia.edu/kermit/ckuins.html#x5.1
- 154. http://www.columbia.edu/kermit/ckuins.html#x5.2
- 155. http://www.columbia.edu/kermit/ckuins.html#x5.3
- 156. http://www.columbia.edu/kermit/ckuins.html#x5.4
- 157. http://www.columbia.edu/kermit/
- 158. http://www.columbia.edu/kermit/ckuins.html#x5.4
- 159. http://www.columbia.edu/kermit/ckuins.html#x5.3
- 160. ftp://kermit.columbia.edu/kermit/c-kermit/COPYING.TXT
- 161. ftp://kermit.columbia.edu/kermit/c-kermit/ckermit.ini
- 162. http://www.columbia.edu/kermit/ckuins.html#x5.1
- 163. ftp://kermit.columbia.edu/kermit/c-kermit/ckermod.ini
- 164. ftp://kermit.columbia.edu/kermit/c-kermit/ckermit70.txt
- 165. http://www.columbia.edu/kermit/ck60manual
- 166. http://www.columbia.edu/kermit/ckermit70.html
- 167. ftp://kermit.columbia.edu/kermit/c-kermit/ckermit80.txt
- 168. http://www.columbia.edu/kermit/ck60manual
- 169. http://www.columbia.edu/kermit/ckermit80.html
- 170. ftp://kermit.columbia.edu/kermit/c-kermit/ckcbwr.txt
- 171. http://www.columbia.edu/kermit/ckcbwr.html
- 172. ftp://kermit.columbia.edu/kermit/c-kermit/ckubwr.txt
- 173. http://www.columbia.edu/kermit/ckubwr.html
- 174. ftp://kermit.columbia.edu/kermit/c-kermit/ckuins.txt
- 175. http://www.columbia.edu/kermit/ckuins.html
- 176. ftp://kermit.columbia.edu/kermit/c-kermit/ckccfg.txt
- 177. http://www.columbia.edu/kermit/ckccfg.html
- 178. ftp://kermit.columbia.edu/kermit/c-kermit/ckcplm.txt
- 179. http://www.columbia.edu/kermit/ckcplm.html
- 180. ftp://kermit.columbia.edu/kermit/c-kermit/ca_certs.pem
- 181. http://www.columbia.edu/kermit/ckuins.html#x16"
- 182. ftp://kermit.columbia.edu/kermit/c-kermit/makefile
- 183. http://www.columbia.edu/kermit/ckuins.html#x?
- 184. http://www.columbia.edu/kermit/ckuins.html#x11
- 185. http://www.columbia.edu/kermit/ckuins.html#x5.2
- 186. http://www.columbia.edu/kermit/ckermit.html#download
- 187. http://www.columbia.edu/kermit/ck80binaries.html
- 188. http://www.columbia.edu/kermit/ckermit.html#download
- 189. http://www.columbia.edu/kermit/ckuins.html#top
- 190. http://www.columbia.edu/kermit/ckuins.html#contents
- 191. http://www.columbia.edu/kermit/ckuins.html#x7
- 192. http://www.columbia.edu/kermit/ckuins.html#x5
- 193. http://www.columbia.edu/kermit/ckuins.html#top
- 194. http://www.columbia.edu/kermit/ckuins.html#contents
- 195. http://www.columbia.edu/kermit/ckuins.html#x8
- 196. http://www.columbia.edu/kermit/ckuins.html#x6
- 197. ftp://kermit.columbia.edu/kermit/c-kermit/ckutio.c
- 198. ftp://kermit.columbia.edu/kermit/c-kermit/ckutio.c
- 199. http://www.columbia.edu/kermit/ckuins.html#x4.0
- 200. ftp://kermit.columbia.edu/kermit/c-kermit/ckcdeb.h
- 201. ftp://kermit.columbia.edu/kermit/c-kermit/ckufio.c
- 202. ftp://kermit.columbia.edu/kermit/c-kermit/ckufio.c
- 203. ftp://kermit.columbia.edu/kermit/c-kermit/ckutio.c
- 204. http://www.columbia.edu/kermit/ckuins.html#x10
- 205. http://www.columbia.edu/kermit/ckccfg.html#x2
- 206. http://www.columbia.edu/kermit/ckccfg.html
- 207. http://www.columbia.edu/kermit/ckuins.html#x4
- 208. http://www.columbia.edu/kermit/ckuins.html#x10
- 209. ftp://kermit.columbia.edu/kermit/c-kermit/ckutio.c
- 210. ftp://kermit.columbia.edu/kermit/c-kermit/ckutio.c
- 211. ftp://kermit.columbia.edu/kermit/c-kermit/ckutio.c
- 212. http://www.columbia.edu/kermit/ckuins.html#x9.4
- 213. mailto:kermit-support@columbia.edu
- 214. http://www.columbia.edu/kermit/ckuins.html#top
- 215. http://www.columbia.edu/kermit/ckuins.html#contents
- 216. http://www.columbia.edu/kermit/ckuins.html#x9
- 217. http://www.columbia.edu/kermit/ckuins.html#x7
- 218. http://www.columbia.edu/kermit/ckccfg.html
- 219. http://www.columbia.edu/kermit/ckccfg.html
- 220. http://www.columbia.edu/kermit/ckuins.html#top
- 221. http://www.columbia.edu/kermit/ckuins.html#contents
- 222. http://www.columbia.edu/kermit/ckuins.html#x10
- 223. http://www.columbia.edu/kermit/ckuins.html#x8
- 224. http://www.columbia.edu/kermit/ckuins.html#x9.1
- 225. http://www.columbia.edu/kermit/ckuins.html#x9.1.1
- 226. http://www.columbia.edu/kermit/ckuins.html#x9.1.2
- 227. http://www.columbia.edu/kermit/ckuins.html#x9.1.3
- 228. http://www.columbia.edu/kermit/ckuins.html#x9.2
- 229. http://www.columbia.edu/kermit/ckuins.html#x9.3
- 230. http://www.columbia.edu/kermit/ckuins.html#x9.4
- 231. http://www.columbia.edu/kermit/ckuins.html#x9.5
- 232. http://www.columbia.edu/kermit/ckuins.html#x9.6
- 233. http://www.columbia.edu/kermit/ckuins.html#x9.7
- 234. http://www.columbia.edu/kermit/ckuins.html#x9.8
- 235. http://www.columbia.edu/kermit/ckuins.html#x9.9
- 236. ftp://kermit.columbia.edu/kermit/c-kermit/ckutio.c
- 237. http://www.columbia.edu/kermit/ckuins.html#top
- 238. http://www.columbia.edu/kermit/ckuins.html#x9
- 239. http://www.columbia.edu/kermit/ckuins.html#contents
- 240. http://www.columbia.edu/kermit/ckuins.html#x9.2
- 241. http://www.columbia.edu/kermit/ckuins.html#x9.1.1
- 242. http://www.columbia.edu/kermit/ckuins.html#x9.1.2
- 243. http://www.columbia.edu/kermit/ckuins.html#x9.1.3
- 244. http://www.columbia.edu/kermit/ckuins.html#top
- 245. http://www.columbia.edu/kermit/ckuins.html#contents
- 246. http://www.columbia.edu/kermit/ckuins.html#x9
- 247. http://www.columbia.edu/kermit/ckuins.html#x9.1
- 248. http://www.columbia.edu/kermit/ckuins.html#x9.1.3
- 249. http://www.columbia.edu/kermit/ckuins.html#x9.1.1
- 250. http://www.columbia.edu/kermit/ckuins.html#top
- 251. http://www.columbia.edu/kermit/ckuins.html#contents
- 252. http://www.columbia.edu/kermit/ckuins.html#x9
- 253. http://www.columbia.edu/kermit/ckuins.html#x9.1
- 254. http://www.columbia.edu/kermit/ckuins.html#x9.2
- 255. http://www.columbia.edu/kermit/ckuins.html#x9.1.2
- 256. http://www.opengroup.org/onlinepubs/007904975/
- 257. http://www.columbia.edu/kermit/ckuins.html#x9.1.1
- 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.3
- 263. http://www.columbia.edu/kermit/ckuins.html#x9.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.4
- 268. http://www.columbia.edu/kermit/ckuins.html#x9.2
- 269. ftp://kermit.columbia.edu/kermit/c-kermit/ckufio.c
- 270. ftp://kermit.columbia.edu/kermit/c-kermit/ckutio.c
- 271. ftp://kermit.columbia.edu/kermit/c-kermit/ckufio.c
- 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.5
- 276. http://www.columbia.edu/kermit/ckuins.html#x9.3
- 277. ftp://kermit.columbia.edu/kermit/c-kermit/ckutio.c
- 278. ftp://kermit.columbia.edu/kermit/c-kermit/ckcdeb.h
- 279. http://www.columbia.edu/kermit/ckuins.html#top
- 280. http://www.columbia.edu/kermit/ckuins.html#contents
- 281. http://www.columbia.edu/kermit/ckuins.html#x9
- 282. http://www.columbia.edu/kermit/ckuins.html#x9.6
- 283. http://www.columbia.edu/kermit/ckuins.html#x9.4
- 284. ftp://kermit.columbia.edu/kermit/c-kermit/ckcdeb.h
- 285. ftp://kermit.columbia.edu/kermit/c-kermit/ckuus3.c
- 286. ftp://kermit.columbia.edu/kermit/c-kermit/ckutio.c
- 287. http://www.columbia.edu/kermit/ckuins.html#top
- 288. http://www.columbia.edu/kermit/ckuins.html#contents
- 289. http://www.columbia.edu/kermit/ckuins.html#x9
- 290. http://www.columbia.edu/kermit/ckuins.html#x9.7
- 291. http://www.columbia.edu/kermit/ckuins.html#x9.5
- 292. http://www.columbia.edu/kermit/ckuins.html#top
- 293. http://www.columbia.edu/kermit/ckuins.html#contents
- 294. http://www.columbia.edu/kermit/ckuins.html#x9
- 295. http://www.columbia.edu/kermit/ckuins.html#x9.8
- 296. http://www.columbia.edu/kermit/ckuins.html#x9.6
- 297. http://www.columbia.edu/kermit/ckuins.html#top
- 298. http://www.columbia.edu/kermit/ckuins.html#contents
- 299. http://www.columbia.edu/kermit/ckuins.html#x9
- 300. http://www.columbia.edu/kermit/ckuins.html#x9.9
- 301. http://www.columbia.edu/kermit/ckuins.html#x9.7
- 302. ftp://kermit.columbia.edu/kermit/c-kermit/ckutio.c
- 303. ftp://kermit.columbia.edu/kermit/c-kermit/ckutio.c
- 304. ftp://kermit.columbia.edu/kermit/c-kermit/ckcdeb.h
- 305. ftp://kermit.columbia.edu/kermit/c-kermit/ckufio.c
- 306. http://www.columbia.edu/kermit/ckuins.html#top
- 307. http://www.columbia.edu/kermit/ckuins.html#contents
- 308. http://www.columbia.edu/kermit/ckuins.html#x9
- 309. http://www.columbia.edu/kermit/ckuins.html#x10
- 310. http://www.columbia.edu/kermit/ckuins.html#x9.8
- 311. http://www.columbia.edu/kermit/ckuins.html#top
- 312. http://www.columbia.edu/kermit/ckuins.html#contents
- 313. http://www.columbia.edu/kermit/ckuins.html#x11
- 314. http://www.columbia.edu/kermit/ckuins.html#x9
- 315. ftp://kermit.columbia.edu/kermit/c-kermit/ckutio.c
- 316. http://www.columbia.edu/kermit/ckuins.html#x11
- 317. http://www.columbia.edu/kermit/ckuins.html#top
- 318. http://www.columbia.edu/kermit/ckuins.html#contents
- 319. http://www.columbia.edu/kermit/ckuins.html#x12
- 320. http://www.columbia.edu/kermit/ckuins.html#x10
- 321. ftp://kermit.columbia.edu/kermit/c-kermit/ckutio.c
- 322. ftp://kermit.columbia.edu/kermit/c-kermit/ckufio.c
- 323. http://www.columbia.edu/kermit/ckuins.html#top
- 324. http://www.columbia.edu/kermit/ckuins.html#contents
- 325. http://www.columbia.edu/kermit/ckuins.html#x13
- 326. http://www.columbia.edu/kermit/ckuins.html#x11
- 327. http://www.columbia.edu/kermit/ckuins.html#top
- 328. http://www.columbia.edu/kermit/ckuins.html#contents
- 329. http://www.columbia.edu/kermit/ckuins.html#x14
- 330. http://www.columbia.edu/kermit/ckuins.html#x12
- 331. ftp://kermit.columbia.edu/kermit/c-kermit/ckubwr.txt
- 332. ftp://kermit.columbia.edu/kermit/c-kermit/ckutio.c
- 333. http://www.columbia.edu/kermit/ckuins.html#top
- 334. http://www.columbia.edu/kermit/ckuins.html#contents
- 335. http://www.columbia.edu/kermit/ckuins.html#x15
- 336. http://www.columbia.edu/kermit/ckuins.html#x13
- 337. http://www.columbia.edu/kermit/ckuins.html#top
- 338. http://www.columbia.edu/kermit/ckuins.html#contents
- 339. http://www.columbia.edu/kermit/ckuins.html#x16
- 340. http://www.columbia.edu/kermit/ckuins.html#x14
- 341. http://www.columbia.edu/kermit/iksd.html#x4.2
- 342. http://www.columbia.edu/kermit/iksd.html
- 343. http://www.columbia.edu/kermit/ckermit2.html
- 344. http://www.columbia.edu/kermit/ckuins.html#top
- 345. http://www.columbia.edu/kermit/ckuins.html#contents
- 346. http://www.columbia.edu/kermit/ckuins.html#x17
- 347. http://www.columbia.edu/kermit/ckuins.html#x15
- 348. http://www.columbia.edu/kermit/security.html
- 349. http://www.columbia.edu/kermit/security80.html
- 350. http://www.columbia.edu/kermit/cuiksd.html
- 351. ftp://kermit.columbia.edu/kermit/c-kermit/ca_certs.pem
- 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/skermit.html
- 356. http://www.columbia.edu/kermit/ckuins.html#top
- 357. http://www.columbia.edu/kermit/ckuins.html#contents
- 358. http://www.columbia.edu/kermit/ckermit.html
- 359. http://www.columbia.edu/kermit/ck80.html
- 360. http://www.columbia.edu/kermit/index.html
projects / ckermit.git / blobdiff