-C-Kermit 8.0 Unix Installation Instructions
+ [1]The Columbia Crown The Kermit Project | Columbia University
+ 612 West 115th Street, New York NY 10025 USA o [2]kermit@columbia.edu
+ ...since 1981
+ [3]Home [4]Kermit 95 [5]C-Kermit [6]Scripts [7]Current [8]New [9]FAQ
+ [10]Support
- [ [1]Contents ] [ [2]C-Kermit ] [ [3]Kermit Home ]
+C-Kermit 9.0 Installation Instructions and Options for Unix
+
+ [ [11]Contents ] [ [12]C-Kermit ] [ [13]Kermit Home ]
Frank da Cruz
The Kermit Project
Columbia University
- As of C-Kermit version: 8.0.211, 10 April 2004
- This file last updated: Tue Apr 13 10:14:33 2004 (New York City
+ As of C-Kermit version: 9.0.300, 30 June 2011
+ This file last updated: Tue Jun 28 08:28:08 2011 (New York City
time)
- IF YOU ARE READING A PLAIN-TEXT version of this document, 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:
+ IF YOU ARE READING A PLAIN-TEXT version of this document, it is a
+ plain-text copy of a Web page. You can visit the original (and possibly
+ more up-to-date) Web page here:
-[4]http://www.columbia.edu/kermit/ckuins.html
- __________________________________________________________________________
+[14]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
- __________________________________________________________________________
+ [15]OVERVIEW
+ 1. [16]INTERNET QUICK START
+ 2. [17]INSTALLING FROM PACKAGES
+ 3. [18]INSTALLING PREBUILT BINARIES
+ 4. [19]BUILDING FROM SOURCE CODE
+ 5. [20]INSTALLING THE KERMIT FILES
+ 6. [21]INSTALLING UNIX C-KERMIT FROM DOS-FORMAT DISKETTES
+ 7. [22]CHECKING THE RESULTS
+ 8. [23]REDUCING THE SIZE OF THE EXECUTABLE PROGRAM IMAGE
+ 9. [24]UNIX VERSIONS
+ 10. [25]DIALING OUT AND COORDINATING WITH UUCP
+ 11. [26]RUNNING UNIX C-KERMIT SETUID OR SETGID
+ 12. [27]CONFIGURING UNIX WORKSTATIONS
+ 13. [28]BIZARRE BEHAVIOR AT RUNTIME
+ 14. [29]CRASHES AND CORE DUMPS
+ 15. [30]SYSLOGGING
+ 16. [31]BUILDING SECURE VERSIONS OF C-KERMIT 9.0
+ 17. [32]INSTALLING C-KERMIT AS AN SSH SERVER SUBSYSTEM
OVERVIEW
- [ [23]Top ] [ [24]Contents ] [ [25]Next ]
+ [ [33]Top ] [ [34]Contents ] [ [35]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.
+ since the mid 1980s. Many of the products and Unix versions
+ mentioned here have not been heard of in a long while, but that does
+ not necessarily mean they are not still running in some obscure
+ nook.
This file contains Unix-specific information. A lot of it. Unlike most
other packages, C-Kermit tries very hard to be portable to every Unix
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
+ configuration options for C-Kermit, please read the [36]Configurations
Options document. For troubleshooting after installation, see the
- [27]General Hints and Tips and [28]Unix-Specific Hints and Tips
+ [37]General Hints and Tips and [38]Unix-Specific Hints and Tips
documents. The latter, in particular, contains lots of information on
lots of specific Unix platforms. If you want to work on the source
- code, see the [29]C-Kermit Program Logic Manual
+ code, see the [39]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
+ * From an "[40]install package", if one is available.
+ * As a [41]prebuilt binary, if available, plus accompanying text
files.
- * By building from [32]source code.
- __________________________________________________________________________
+ * By building from [42]source code.
1. INTERNET QUICK START
- [ [33]Top ] [ [34]Contents ] [ [35]Next ] [ [36]Previous ]
+ [ [43]Top ] [ [44]Contents ] [ [45]Next ] [ [46]Previous ]
If your Unix computer is on the Internet and it has a C compiler,
here's how to download, build, and install C-Kermit directly from the
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).
+ [47]ftp://www.columbia.edu/kermit/archives/cku211.tar.Z (compress
+ format) or [48]ftp://www.columbia.edu/kermit/archives/cku211.tar.gz
+ (gunzip format). If those links don't work, FTP transfers are being
+ blocked; try these HTTP links instead:
+ [49]http://kermit.columbia.edu/ftp/archives/cku211.tar.Z (compress
+ format) or
+ [50]http://kermit.columbia.edu/ftp/archives/cku211.tar.gz (gunzip
+ format).
3. Uncompress the compressed tar file with "uncompress" or "gunzip",
according to which type of compressed file you downloaded. (If you
don't understand this, you could download a (much larger)
uncompressed tar archive directly:
- [39]ftp://kermit.columbia.edu/kermit/archives/cku211.tar
+ [51]ftp://www.columbia.edu/kermit/archives/cku211.tar or
+ [52]http://kermit.columbia.edu/ftp/archives/cku211.tar
4. Now type "tar xvf cku211.tar" to unpack the individual files from
the tar archive.
5. Type "rm cku211.tar" to get rid of the tar archive, which is no
longer needed.
6. Read the comments at the top of the makefile to find out which
- target to use and then type the appropriate "make" command, such
- as "make linux", "make solaris8", etc.
+ 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
+ Start it by typing "./wermit" and [53]try it out to make sure it
+ works. Then read [54]Section 5 for how to install it, or simply
copy the wermit binary to the desired public directory, rename it
to kermit, and give it the needed permissions (and, if it is going
to be used to dial out, give it the same group and owner and
permissions as the cu, tip, or minicom program).
- For secure installations, see [42]Sections 5 and [43]16.
- __________________________________________________________________________
+ For secure installations, see [55]Sections 5 and [56]16.
2. INSTALLING FROM PACKAGES
- [ [44]Top ] [ [45]Contents ] [ [46]Next ] [ [47]Previous ]
+ [ [57]Top ] [ [58]Contents ] [ [59]Next ] [ [60]Previous ]
Various Unix varieties -- Linux, Solaris, AIX, etc -- now incorporate
the idea of "install packages", and many users expect to find all new
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
+ AOS/VS, etc), some of the files in the C-Kermit distribution do not
+ fit into the Unix application model. In particular, C-Kermit
+ includes some plain text files (described in [61]Section 5) and
Unix has no standard place to put such files. Typical Unix package
managers do not allow for them. Where should they go, and how will
the user know where to find them?
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
+ Item (b) is discussed at length in [62]Sections 10 and [63]11 of this
document, but the package-related aspects are also given here. The
basic problem is that Unix dialout devices and the UUCP "lock files"
- that regulate contention for them (described in [51]Section 10) are
+ that regulate contention for them (described in [64]Section 10) are
usually protected against "world". Therefore, the install procedure
- must either run as root in order to give the Kermit binary the
- required permissions, group, and/or owner, or else the dialout devices
- and associated directories must be open for group or world reading and
- writing. Otherwise, the Kermit program just installed WILL NOT WORK
- for dialing out.
+ 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:
+ accesss 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:
+ devices. If they do not allow group or world R/W accesss, then:
b. "Your UUCP lockfile directory and/or dialout devices require
- privilege to access. You must either change their permissions or
+ privilege to accesss. 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."
+ use the dialout devices." (This is increasingly problematic as some
+ newer Unix systems like Mac OS X don't have a cu program, or even a
+ serial port!)
d. If they choose (c) but the user is not root, give a message that
the install procedure can be run only by root and then quit.
It should go without saying, of course, that any binaries that are to
be included in an install package should be built fresh on the exact
- platform (e.g. Red Hat 8.0 on Intel) for which the package is
- targeted; prebuilt binaries ([52]next section) from other sites are
- likely to have library mismatches. [53]CLICK HERE for more about
- building C-Kermit install packages.
+ platform (e.g. Red Hat 8.0 on Intel) for which the package is targeted;
+ prebuilt binaries ([65]next section) from other sites are likely to
+ have library mismatches. [66]CLICK HERE for more about building
+ C-Kermit install packages.
- The Kermit Project does not have the resources or the expertise to
- make install packages for every platform. Most install packages,
- therefore, are contributed by others, and they do not necessarily
- follow the guidelines given above. Pay attention to what they do.
+ 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.
- __________________________________________________________________________
+ might needed if you want to use Kermit to dial out. Read [67]Section 10
+ for details.
3. INSTALLING PREBUILT BINARIES
- [ [55]Top ] [ [56]Contents ] [ [57]Next ] [ [58]Previous ]
+ [ [68]Top ] [ [69]Contents ] [ [70]Next ] [ [71]Previous ]
Hundreds of prebuilt C-Kermit binaries are available on the CDROM in
the BINARY tree [NOTE: The C-Kermit CDROM is still for version 7.0],
- and at our ftp site in the [59]kermit/bin area (with names starting
- with "ck"), also accessible on the [60]C-Kermit website. To install a
+ and at our ftp site in the [72]kermit/bin area (with names starting
+ with "ck"), also accesssible on the [73]C-Kermit website. To install a
prebuilt binary:
a. Rename the binary to "wermit".
- b. Make sure it works; some tests are suggested in [61]Section 7.
- c. Follow steps (b) through (e) in [62]Section 4.
- d. Install related files as described in [63]Section 5.
+ b. Make sure it works; some tests are suggested in [74]Section 7.
+ c. Follow steps (b) through (e) in [75]Section 4.
+ d. Install related files as described in [76]Section 5.
But first... Please heed the following cautions:
a. If you pick the wrong binary, it won't work (or worse).
b. Even when you pick the appropriate binary, it still might not work
- due to shared-library mismatches, etc. (see [64]Section 4.0).
+ due to shared-library mismatches, etc. (see [77]Section 4.0).
c. Don't expect a binary built on or for version n of your OS to work
- on version n - x (where x > 0). However, it is 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.
- __________________________________________________________________________
+ on version n - x (where x > 0). However, it is supposed to be safe
+ to run a binary built on (or for) an older OS release on a newer
+ one (but is [78]increasingly less so as time-honored principles of
+ stability and backwards compatibility go fading into obscurity).
+
+ Therefore, it is always better to build your own binary from source
+ code ([79]next section) if you can. But since it is increasingly common
+ for Unix systems (not to mention VMS and other OS's) to be delivered
+ without C compilers, it is sometimes not possible. In such cases, try
+ the most appropriate prebuilt binary or binaries, and if none of them
+ work, [80]contact us and we'll see what we can do to help.
4. BUILDING FROM SOURCE CODE
- [ [67]Top ] [ [68]Contents ] [ [69]Next ] [ [70]Previous ]
+ [ [81]Top ] [ [82]Contents ] [ [83]Next ] [ [84]Previous ]
- Also see: [71]Section 8 and [72]Section 9.
+ Also see: [85]Section 8 and [86]Section 9.
C-Kermit is designed to be built and used on as many platforms as
- possible: Unix and non-Unix, old and new (and ancient), ANSI C and
- K&R. The Unix version does not use or depend on any external tools for
- building except the "make" utility, the C compiler, 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
+ possible: Unix and non-Unix, old and new (and ancient), ANSI C and K&R.
+ The Unix version does not use or depend on any external tools for
+ building except the "make" utility, the C compiler, the linker, and the
+ shell. It does not use any external automated configuration tools such
+ as configure, autoconf, automake, libtool, etc. Everything in C-Kermit
+ has been built by hand based on direct experience or reports or
+ contributions from users of each platform.
+
+ The [87]C-Kermit makefile contains the rules for building the program
for each of the hundreds of different kinds of Unix systems that
- C-Kermit attempts to support. It covers all Unix variations since
- about 1980 -- pretty much everything after Unix V6. Separate makefiles
- are used for [74]Plan 9 and [75]2.x BSD.
+ C-Kermit attempts to support. It covers all Unix variations since about
+ 1980 -- pretty much everything after Unix V6. Separate makefiles are
+ used for [88]Plan 9 and [89]2.x BSD.
Prerequisites:
* The C compiler, linker, and make program must be installed.
* The C libraries and header files must be installed (*).
* The C-Kermit source code and makefile in your current directory.
- * The C-Kermit text files ([76]Section 5) in your current directory.
+ * The C-Kermit text files ([90]Section 5) in your current directory.
* This is becoming problematic in this new age of "selective
installs" e.g. of Linux packages. C-Kermit builds will often fail
* 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
+ * For the curses-based fullscreen file-transfer 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
+ of these files and libraries are likely to change capriciously with
+ every new release of your Unix product. If you discover that the
+ C-Kermit build procedure fails because your curses and/or termxxx
+ headers or libraries are not named or located as expected, please
+ [91]let us know. In the meantime, work around by installing
symlinks.
* IMPORTANT: Modern Linux distributions might give you the choice
during installation of whether to install the "ncurses development
package" (perhaps called "ncurses-devel"). If you did not install
it, you won't be able to build C-Kermit with curses support
- included. In this case, either go back and install ncurses, or
- else choose (or create) a non-curses makefile target for your
- platform. To install the ncurses developers tools in Red Hat
- Linux, do:
+ included. In this case, either go back and install ncurses, or else
+ choose (or create) a non-curses makefile target for your platform.
+ To install the ncurses developers tools in Red Hat Linux, do
+ "apt-get install ncurses-developer" or if you have the CD:
mount redhat cdrom
goto RedHat/RPMS
from the first installation CD.
- The makefile might need to be renamed from ckuker.mak to makefile.
- Directions:
+ Depending on where you got it, the makefile might need to be renamed
+ from ckuker.mak to makefile. Directions:
a. Type "make xxx" where xxx is the name of the makefile target most
- appropriate to your platform, e.g. "make linux", "make aix43",
- etc. Read the [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.
+ appropriate to your platform, e.g. "make linux", "make aix43", etc.
+ Read the [92]comments at the top of the makefile for a complete
+ list of available targets (it's a long list).
+ b. Test the resulting 'wermit' file (see [93]Section 7 for
+ suggestions). If it's OK, proceed; otherwise [94]notify us.
NOTE: steps (c) through (e) can be accomplished using the
- [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).
+ [95]makefile 'install' target as described in [96]Section 5.4.
+ c. Rename the 'wermit' file to 'kermit', copy it to the desired binary
+ directory (such as /usr/local/bin or /opt/something), and if it is
+ to be used for dialing out, give it the same owner, group, and
+ permissions as the 'cu' program (IMPORTANT: read [97]Sections 10
+ and [98]11 for details).
d. Install the man page, ckuker.nr, with your other man pages.
- e. Install the accompanying text files (see [85]Section 5).
+ e. Install the accompanying text files (see [99]Section 5).
f. If you want C-Kermit to also offer a Telnet command-line
personality, make a symbolic link as follows:
cd directory-where-kermit-binary-is
ln -s kermit telnet
- If you want C-Kermit to be the default Telnet client, make sure
- the directory in which you created the symlink is in the PATH
- ahead of the where the regular Telnet client is.
- g. If you want C-Kermit to also offer an FTP command-line
- personality, make a symlink called "ftp" as in (f).
+ 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.
- ________________________________________________________________________
+ directions in the [100]IKSD Administrator's Guide.
- 4.0. Special Considerations for C-Kermit 8.0
+4.0. Special Considerations for C-Kermit 8.0-9.0
- [ [87]Top ] [ [88]Contents ] [ [89]Next ]
+ [ [101]Top ] [ [102]Contents ] [ [103]Next ]
- Also see: [90]C-Kermit Configuration Options
+ Also see: [104]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
+4.1. [105]The Unix Makefile
+4.2. [106]The C-Kermit Initialization File
+4.3. [107]The 2.x BSD Makefile
+4.4. [108]The Plan 9 Makefile
+4.5. [109]Makefile Failures
- (Also see the [96]Configurations Options document, [97]Section 8).
+ (Also see the [110]Configurations Options document, [111]Section 8).
Lots of new features have been added in versions 7.0 and 8.0 that
- require access to new symbols, APIs, libraries, etc, and this will no
+ require accesss 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 [112]IKSD Administrator's Guide for details):
The wtmp File
When C-Kermit is started as an IKSD (under inetd), it makes
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
+ (there is also a runtime override). See [113]iksd.html for
details.
UTMP, utsname(), etc
- C-Kermit 7.0 gets as much info as it can about its job --
- mainly for IKSD logging -- from utmp. But of course utmp
- formats and fields differ, and for that matter, there can be
- two different header files, <utmp.h> and <utmpx.h>. Look for
- HAVEUTMPX and HAVEUTHOST in [100]ckufio.c and let me know of
- any needed adjustments.
+ C-Kermit 7.0 gets as much info as it can about its job -- mainly
+ for IKSD logging -- from utmp. But of course utmp formats and
+ fields differ, and for that matter, there can be two different
+ header files, <utmp.h> and <utmpx.h>. Look for HAVEUTMPX and
+ HAVEUTHOST in [114]ckufio.c and let me know of any needed
+ adjustments.
Password lookup
IKSD needs to authenticate incoming users against the password
- list. In some cases, this requires the addition of -lcrypt
- (e.g. in Unixware 2.x). In most others, the crypt functions are
- in the regular C library. If you get "crypt" as an unresolved
- symbol at link time, add -lcrypt to LIBS. If your site has
- local replacement libraries for authentication, you might need
- a special LIBS clause such as "LIBS=-L/usr/local/lib -lpwent".
+ 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
+ files or Pluggable Authentication Modules (PAM). If your system
uses shadow passwords you must add -DCK_SHADOW to the CFLAGS
list. If your system requires PAM you must add -DCK_PAM to the
CFLAGS and -lpam -ldl to LIBS.
-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.
+ 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.
+ [115]ckufio.c, and [116]let us know.
printf()
IKSD installs a printf() substitute to allow redirection of
- printf-like output to the connection. However, this can
- conflict with some curses libraries. In this case, separate
- binaries must be built for IKSD and non-IKSD use.
+ 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
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.:
+ The main() routine is in [117]ckcmai.c. If you get complaints
+ about "main: return type is not blah", define MAINTYPE on the CC
+ command line, e.g.:
make xxx "KFLAGS=-DMAINTYPE=blah
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.
+ 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
+ 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.
+ -lsocket to LIBS (SCO OSR5 is an example). See [118]Section 15.
putenv()
If "_putenv" comes up as an undefined symbol, add -DNOPUTENV to
"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.
+ module, [119]ckutio.c or [120]ckufio.c.
gettimeofday()
Wrong number of arguments. On most platforms, gettimeofday()
takes two arguments, but on a handful of others (e.g. Motorola
System V/88 V4, SNI Reliant UNIX 5.43, etc) it takes one. If
- your version of gettimeofday() is being called with two args
- but wants one, add -DGTODONEARG.
+ 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:
+ This warning might appear in [121]ckutio.c or [122]ckufio.c. (or
+ elsewhere), and usually can be traced to the use of a system or
+ library function that returns a pointer but that is not declared
+ in the system header files even though it should be. Several
+ functions are commonly associated with this error:
+ getcwd(): Add -DDCLGETCWD to CFLAGS and rebuild.
+ popen() : Add -DDCLPOPEN to CFLAGS and rebuild.
"Operands of = have incompatible types"
"Incompatible types in assignment"
- If this comes from [109]ckcnet.c and comes from a statement
+ If this comes from [123]ckcnet.c and comes from a statement
involving inet_addr(), try adding -DINADDRX to CFLAGS. If that
doesn't help, then try adding -DNOMHHOST.
- Complaints about args to get/setsockopt(), getpeername(),
- getsockname()
- These are all in [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.
+ Complaints about args to get/setsockopt(), getpeername(), getsockname()
+ These are all in [124]ckcnet.c. Different platforms and OS's and
+ versions of the same OS change this all the time: int, size_t,
+ unsigned long, etc. All the affected variables are declared
+ according to #ifdefs within ckcnet.c, so find the declarations
+ and adjust the #ifdefs accordingly.
size_t
In case of complaints about "unknown type size_t", add
'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
+ similar complaints in [125]ckutio.c: Add -DNOGFTIMER and/or
-DNOTIMEVAL.
Symlinks
- The new built-in DIRECTORY command should show symlinks like
- "ls -l" does. If it does not, check to see if your platform has
- the lstat() and readlink() functions. If so, add -DUSE_LSTAT
- and -DCKSYMLINK to CFLAGS and rebuild. On the other hand, if
- lstat() is unresolved at link time, add -DNOLSTAT to CFLAGS. If
+ 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()
"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.
+ 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:
-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).
+ 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.
+ 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
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.
+ (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)
+ Switch Table Overflow (in [126]ckcuni.c)
Add -DNOUNICODE to CFLAGS.
Compile-time warnings about ck_out() or tgetstr() or tputs():
-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.
+ 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 -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.
+ 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
- ________________________________________________________________________
+[127]kermit-support@columbia.edu
- 4.1. The Unix Makefile
+4.1. The Unix Makefile
- [ [114]Top ] [ [115]Contents ] [ [116]Section Contents ] [ [117]Next ]
- [ [118]Previous ]
+ [ [128]Top ] [ [129]Contents ] [ [130]Section Contents ] [ [131]Next ]
+ [ [132]Previous ]
If your distribution does not contain a file with the name "makefile"
or "Makefile", then rename the file called ckuker.mak to makefile:
mv ckuker.mak makefile
Then type "make xxx", where xxx is the platform you want to build
- C-Kermit for. These are listed in the [119]comments at the top of the
+ C-Kermit for. These are listed in the [133]comments at the top of the
makefile. For example, to build C-Kermit for Linux, type:
make linux
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.)
+ 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
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 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).
+ Check to see if there are comments about your particular version in the
+ [134]ckubwr.txt file ([135]CLICK HERE for the Web version).
- If you have trouble with building [122]ckwart.c, or running the
- resulting wart preprocessor program on [123]ckcpro.w:
+ If you have trouble with building [136]ckwart.c, or running the
+ resulting wart preprocessor program on [137]ckcpro.w:
- 1. Just "touch" the [124]ckcpro.c file that comes in the distribution
+ 1. Just "touch" the [138]ckcpro.c file that comes in the distribution
and then give the "make" command again, or:
2. Compile ckwart.c "by hand": cc -o wart ckwart.c, or:
3. Try various other tricks. E.g. one Linux user reported that that
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).
+ 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:
+ 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"
"-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.
+ 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
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
+4.2. The C-Kermit Initialization File
- [ [125]Top ] [ [126]Contents ] [ [127]Section Contents ] [ [128]Next ]
- [ [129]Previous ]
+ [ [139]Top ] [ [140]Contents ] [ [141]Section Contents ] [ [142]Next ]
+ [ [143]Previous ]
- (This section is obsolete.) Read [130]Section 5 about the
+ (This section is obsolete.) Read [144]Section 5 about the
initialization file.
- ________________________________________________________________________
- 4.3. The 2.x BSD Makefile
+4.3. The 2.x BSD Makefile
- [ [131]Top ] [ [132]Contents ] [ [133]Section Contents ] [ [134]Next ]
- [ [135]Previous ]
+ [ [145]Top ] [ [146]Contents ] [ [147]Section Contents ] [ [148]Next ]
+ [ [149]Previous ]
This section is obsolete. C-Kermit 6.0 was the last release that
could be built on PDP-11 based BSD versions.
- ________________________________________________________________________
- 4.4. The Plan 9 Makefile
+4.4. The Plan 9 Makefile
- [ [136]Top ] [ [137]Contents ] [ [138]Section Contents ] [ [139]Next ]
- [ [140]Previous ]
+ [ [150]Top ] [ [151]Contents ] [ [152]Section Contents ] [ [153]Next ]
+ [ [154]Previous ]
- Use the separate makefile [141]ckpker.mk. NOTE: The Plan 9 version of
+ Use the separate makefile [155]ckpker.mk. NOTE: The Plan 9 version of
C-Kermit 8.0 has not yet been built. There should be no impediment to
building it. However, even when built successfully, certain key
features are missing, notably TCP/IP networking.
- ________________________________________________________________________
- 4.5. Makefile Failures
+4.5. Makefile Failures
- [ [142]Top ] [ [143]Contents ] [ [144]Section Contents ] [
- [145]Previous ]
+ [ [156]Top ] [ [157]Contents ] [ [158]Section Contents ] [
+ [159]Previous ]
First, be sure the source files are stored on your current disk and
directory with the right names (in lowercase). Second, make sure that
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.
+ 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.
+ 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
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
+ the most appropriate [160]makefile target, and be sure you have
installed an SCO development system that is keyed to your exact SCO
operating system release, down to the minor version (like 2.3.1).
- Also note that SCO distributes some of its libraries in encrypted
- form, and they must be decrypted before C-Kermit can be linked with
- them. If not, you might see a message like:
+ 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 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
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 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.
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 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 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
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:
+ the -O (optimize) option is included in the make entry. If this happens
+ to you, you can (a) remove the -O option from the make entry, which
+ will turn off the optimizer for ALL modules; or (b) compile the
+ offending module(s) by hand, including all the switches from make entry
+ except for -O, and then give the appropriate "make" command again; or
+ (c) increase the value of the -Olimit option, if your compiler supports
+ this option; or (d) change the [161]makefile target to first compile
+ each offending module explicitly without optimization, then compile the
+ others normally (with optimization), for example:
#Fortune 32:16, For:Pro 2.1 (mostly like 4.1bsd)
ft21:
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.
+ generates ckcpro.c automatically from [162]ckcpro.w, which translates
+ lex-like state/input constructions into a big switch/case construction.
Some function in Kermit wreaks havoc when it is called. Change all
invocations of the function into a macro that evaluates to the
appropriate return code that would have been returned by the function
- had it been called and failed, for example: -Dzkself()=0. Obviously
- not a good idea if the function is really needed.
+ 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
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 ]
+ [ [163]Top ] [ [164]Contents ] [ [165]Next ] [ [166]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
+5.1. [167]The C-Kermit Initialization File
+5.2. [168]Text Files
+5.3. [169]Installing the Kermit Files
+5.4. [170]The Makefile Install Target
The C-Kermit executable does not need any external files to run.
Unlike, say, the cu program, which on most platforms is useless unless
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.
+ 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
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/
+[171]http://www.columbia.edu/kermit/
- and usually in a more pleasant form, perhaps also with updated
- content. So if your computer is on the Internet, there is no need to
- install anything but the Kermit executable if users know how to find
- the Kermit website (and if they don't, Kermit's "help" command tells
- them).
+ 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
+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:
+ 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.
+ 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.
+ 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
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.
+ 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.
+ 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.
+ The full pathname of one or more Kermit network directory files.
+ Equivalent to SET NETWORK DIRECTORY.
K_INFO_DIRECTORY
K_INFO_DIR
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.
+ 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
+ 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_PBX_XCH
The telephonic numeric PBX exchange (first part of the
- subscriber number). Equivalent to Kermit's SET DIAL
- PBX-EXCHANGE command.
+ 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.
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:
+ 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.
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).
+ than $HOME/.kermrc to avoid being executed automatically every time
+ you start Kermit), or you can make it a kerbang script and execute
+ it "directly" (the [172]makefile install target does this for you
+ by putting ckermit.ini in the same directory as the Kermit binary,
+ adding the appropriate Kerbang line to the top, and giving it
+ execute permission).
In fact, you can put any number of kerbang scripts in your PATH to
- start up C-Kermit in different ways, to have it adopt certain
- settings, make particular connections, execute complicated scripts,
- whatever you want.
+ 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
+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.
+ These are entirely optional. Many of them are to be found at the Kermit
+ website in HTML form (i.e. as Web pages with clickable links, etc), and
+ very likely also more up to date. Plain-text files that correspond to
+ Web pages were simply "dumped" by Lynx from the website to plain ASCII
+ text. The format is whatever Lynx uses for this purpose. If you wish,
+ you can install them on your computer as described in the [173]next
+ section.
- [160]COPYING.TXT
+ [174]COPYING.TXT
Copyright notice, permissions, and disclaimer.
- [161]ckermit.ini
+ [175]ckermit.ini
The standard initialization file, intended more for reference
- (in most cases) than actual use; see [162]Section 5.1.
+ (in most cases) than actual use; see [176]Section 5.1.
- [163]ckermod.ini
+ [177]ckermod.ini
A sample customization file.
- [164]ckermit70.txt
- Supplement to [165]Using C-Kermit for version 7.0. Available on
+ [178]ckermit70.txt
+ Supplement to [179]Using C-Kermit for version 7.0. Available on
the Kermit website as:
- [166]http://www.columbia.edu/kermit/ckermit70.html
+ [180]http://www.columbia.edu/kermit/ckermit70.html
- [167]ckermit80.txt
- Supplement to [168]Using C-Kermit for version 8.0. Available on
+ [181]ckermit80.txt
+ Supplement to [182]Using C-Kermit for version 8.0. Available on
the Kermit website as:
- [169]http://www.columbia.edu/kermit/ckermit80.html
+ [183]http://www.columbia.edu/kermit/ckermit80.html
- [170]ckcbwr.txt
+ [184]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
+ [185]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
+ [186]ckubwr.txt
+ The Unix-specific C-Kermit hints and tips file. Available on the
+ Kermit website as:
+ [187]http://www.columbia.edu/kermit/ckubwr.html
- [174]ckuins.txt
+ [188]ckuins.txt
Unix C-Kermit Installation Instructions (this file). Available
on the Kermit website as:
- [175]http://www.columbia.edu/kermit/ckuins.html
+ [189]http://www.columbia.edu/kermit/ckuins.html
- [176]ckccfg.txt
+ [190]ckccfg.txt
C-Kermit compile-time configuration options. Available on the
Kermit website as:
- [177]http://www.columbia.edu/kermit/ckccfg.html
+ [191]http://www.columbia.edu/kermit/ckccfg.html
- [178]ckcplm.txt
+ [192]ckcplm.txt
The C-Kermit program logic manual. Available on the Kermit
website as:
- [179]http://www.columbia.edu/kermit/ckcplm.html
+ [193]http://www.columbia.edu/kermit/ckcplm.html
- [180]ca_certs.pem
+ [194]ca_certs.pem
Certificate Authority certificates for secure connections (see
- [181]Section 16).
+ [195]Section 16).
- 5.3. Installing the Kermit Files
+5.3. Installing the Kermit Files
- There is an "install" target in the [182]makefile that you can use if
+ There is an "install" target in the [196]makefile that you can use if
you wish. However, since every site has its own layout and
requirements, it is often better to install the Kermit files by hand.
You don't have to use the makefile install target to install C-Kermit.
- This is especially true since not all sites build C-Kermit from
- source, and therefore might not even have the makefile. But you should
- read this section in any case.
-
- If your computer already has an older version of C-Kermit
- installed, you should rename it (e.g. to "kermit6" or "kermit7") so
- in case you have any trouble with the new version, the old one is
- still available.
-
- In most cases, you need to be root to install C-Kermit, if only to
- gain write access to directories in which the binary and manual page
- are to be copied. The C-Kermit binary should be installed in a
- directory that is in the users' PATH, but that is not likely to be
- overwritten when you install a new version of the operating system. A
- good candidate would be the /usr/local/bin/ directory, but the
- specific choice is site dependent. Example (assuming the appropriate
- Kermit binary is stored in your current directory as "wermit", e.g.
- because you just built it from source and that's the name the makefile
- gave it):
+ 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 accesss 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
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
+ something to give it accesss 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
+ [197]Sections 10 and [198]11 below, make the necessary decisions, and
then implement them by hand as described in those sections.
- You should also install the man page, which is called ckuker.nr, in
- the man page directory for local commands, such as /usr/man/man1/,
- renamed appropriately, e.g. to kermit.1. This is also taken care of by
- "make install".
+ 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:
+ Optionally, the text files listed in the [199]previous section can be
+ placed in a publicly readable directory. Suggested directory names are:
/usr/local/doc/kermit/
/usr/local/lib/kermit/
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.
+ 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
+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
+ * You downloaded the [200]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"
+ * You downloaded an [201]individual C-Kermit binary and the
+ [202]C-Kermit text-file archive, and your computer has a "make"
command.
Here are the parameters you need to know:
"wermit".
prefix
- (lower case) If you define this variable, its value is
- prepended to all the following xxxDIR variables (8.0.211 and
- later).
+ (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.
+ 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.
+ 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.
+ Default: /usr/man/man1. If MANDIR is defined, the directory must
+ already exist.
MANEXT
Extension for the manual page. Default: 1 (digit one).
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.
+ 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
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.
+ 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
SRCDIR =
INFODIR =
CERTDIR =
- __________________________________________________________________________
6. INSTALLING UNIX C-KERMIT FROM DOS-FORMAT DISKETTES
- [ [189]Top ] [ [190]Contents ] [ [191]Next ] [ [192]Previous ]
+ [ [203]Top ] [ [204]Contents ] [ [205]Next ] [ [206]Previous ]
This section is obsolete. We don't distribute C-Kermit on diskettes
- any more because (a)there is no demand, and (b) it no longer fits.
+ 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
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:
+ 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
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.
- __________________________________________________________________________
+ /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 ]
+ [ [207]Top ] [ [208]Contents ] [ [209]Next ] [ [210]Previous ]
First some quick checks for problems that can be easily corrected by
recompiling with different options:
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.
+ of C-Kermit was built correctly for your Unix system, with hints on how
+ to fix or work around problems:
+
+ a. Start C-Kermit (usually by typing "./wermit" in the directory where
+ you ran the makefile). Do you see the C-Kermit> prompt? If not,
+ C-Kermit incorrectly deduced that it was running in the background.
+ The test is in conbgt() in [211]ckutio.c. If you can fix it for
+ your system, please send in the fix (Hint: read about "PID_T"
+ below). Otherwise, you can force C-Kermit to foreground mode by
+ starting it with the -z command line option, as in "kermit -z", or
+ giving the interactive command SET BACKGROUND OFF.
b. When you type characters at the C-Kermit prompt, do they echo
immediately? If not, something is wrong with concb() and probably
- the other terminal mode settings routines in [198]ckutio.c. Be
- sure you have used the most appropriate make entry.
+ the other terminal mode settings routines in [212]ckutio.c. Be sure
+ you have used the most appropriate make entry.
c. At the C-Kermit> prompt, type "send ./?". C-Kermit should list all
the files in the current directory. If not, it was built for the
- wrong type of Unix file system. Details below. In the meantime,
- try SET WILDCARD-EXPANSION SHELL as a workaround.
+ 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.:
+ see [213]Section 4.0.
+ e. Assuming your platform supports long file names, create a file with
+ a long name in your current directory, e.g.:
$ touch thisisafilewithaveryveryveryveryveryveryveryverylooooooooongname
- (you might need to make it longer than this, perhaps as long as
- 257 or even 1025 characters).
+ (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
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
+ [214]ckcdeb.h to see how the symbol CKMAXPATH is set and make any
needed adjustments.
g. Send a file to your new Kermit program from a different Kermit
program that is known to work. Is the date/timestamp of the new
file identical to the original? If not, adjustments are needed in
- zstrdt() in [201]ckufio.c.
+ zstrdt() in [215]ckufio.c.
h. Go to another computer (Computer B) from which you can send files
to C-Kermit. Connect Computer B to the computer (A) where you are
testing C-Kermit. Then:
i. Send a file from B to A. Make sure it transferred OK and was
created with the the right name.
- j. Send a file from B to A, specifying an "as-name" that is very,
- very long (longer than the maximum name length on computer A).
- Check to make sure that the file was received OK and that its name
- was truncated to Computer A's maximum length. If not, check the
- MAXNAMLEN definition in [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
+ j. Send a file from B to A, specifying an "as-name" that is very, very
+ long (longer than the maximum name length on computer A). Check to
+ make sure that the file was received OK and that its name was
+ truncated to Computer A's maximum length. If not, check the
+ MAXNAMLEN definition in [216]ckufio.c.
+ k. Tell C-Kermit on Computer A to "set receive pathnames relative" and
+ then send it a file from Computer B specifying an as-name that
contains several directory segments:
send foo dir1/dir2/dir3/foo
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.
+ version of C-Kermit was probably built with -DNOJC. If your session
+ became totally frozen, then you are probably running C-Kermit on a
+ Unix version that supports job control, but under a shell that
+ doesn't. If that's not the case, look in the congm() and psuspend()
+ routines in [217]ckutio.c and see if you can figure out what's
+ wrong. If you can't, rebuild with -DNOJC.
o. Give a SET LINE command for a dialout device, e.g. "set line
- /dev/tty00". If you got some kind of permission or access denied
- message, go read [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?
+ /dev/tty00". If you got some kind of permission or accesss denied
+ message, go read [218]Section 10 and then come back here.
+ p. After giving a successful SET LINE command, type "show comm" to see
+ the communication parameters. Do they make sense?
q. Type "set speed ?" and observe the list of available speeds. Is it
- what you expected? If not, see [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.)
+ what you expected? If not, see [219]Section 2) of the
+ [220]Configurations Options document.
+ r. Give a SET SPEED command to change the device's speed. Did it work?
+ (Type "show comm" again to check.)
s. Try dialing out: SET MODEM TYPE , SET LINE , SET SPEED , DIAL . If
it doesn't work, keep reading. After dialing, can you REDIAL?
t. If your version was built with TCP/IP network support, try the
(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.
+ support, check that it works during local-mode file transfer. Also,
+ check C-Kermit's operation afterwards: is the echoing funny? etc
+ etc. If there are problems, see [221]Section 4.
+ x. If your version was built with script programming language support,
+ TAKE the ckedemo.ksc file to give it a workout.
y. Does C-Kermit interlock correctly with UUCP-family programs (cu,
- tip, uucp, etc)? If not, read the section [208]DIALING OUT AND
+ tip, uucp, etc)? If not, read the section [222]DIALING OUT AND
COORDINATING WITH UUCP below.
z. Modem signals... Give a SET LINE command to a serial device and
then type the SHOW MODEM command. If it says "Modem signals
- unavailable in this version of Kermit", then you might want to
- look at the ttgmdm() routine in [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).
+ unavailable in this version of Kermit", then you might want to look
+ at the ttgmdm() routine in [223]ckutio.c and add the needed code --
+ if indeed your version of Unix provides a way to get modem signals
+ (some don't; e.g. modem signals are a foreign concept to POSIX,
+ requiring politically incorrect workarounds).
aa. If it says "Modem signals unavailable", then it is likely that the
API for getting modem signals is provided, but it doesn't actually
do anything (e.g. ioctl(ttyfd,TIOCMGET,&x) returns EINVAL).
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.
+ [224]ckutio.c.
ac. If your version of Kermit has the SET FLOW RTS/CTS command, check
to see if it works: give Kermit this command, set your modem for
RTS/CTS, transfer some files (using big packet and window sizes)
and watch the RTS and CTS lights on the modem. If they go on and
- off (and Kermit does not get packet errors), then it works. If
- your version of Kermit does not have this command, but your
- version of Unix does support hardware flow control, take a look at
- the tthflow() command in [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
+ off (and Kermit does not get packet errors), then it works. If your
+ version of Kermit does not have this command, but your version of
+ Unix does support hardware flow control, take a look at the
+ tthflow() command in [225]ckutio.c and see if you can add the
+ needed code (see the section on [226]HARDWARE FLOW CONTROL below).
+ (And please [227]send back any added code, so that others can
benefit from it and it can be carried forward into future
releases.)
ad. If C-Kermit starts normally and issues its prompt, echoing is
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,
+ accesss 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 ]
+ [ [228]Top ] [ [229]Contents ] [ [230]Next ] [ [231]Previous ]
- Also see: [218]C-Kermit Configuration Options
+ Also see: [232]C-Kermit Configuration Options
a. Many of C-Kermit's options and features can be deselected at
compile time. The greatest savings at the least sacrifice in
functionality is to disable the logging of debug information by
- defining NODEBUG during compilation. See the [219]Configurations
+ defining NODEBUG during compilation. See the [233]Configurations
Options document for further information.
b. Use shared libraries rather than static linking. This is the
- default on many Unix systems anyway. However, executables built
- for dynamic linking with shared libraries are generally not
- portable away from the machine they were built on, so this is
- recommended if the binary is for your use only.
+ 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
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 ]
+ [ [234]Top ] [ [235]Contents ] [ [236]Next ] [ [237]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
+9.1 [238]Standards
+ 9.1.1. [239]POSIX
+ 9.1.2. [240]ANSI C
+ 9.1.3. [241]Other Standards
+9.2. [242]Library Issues
+9.3. [243]Unix File System Peculiarities
+9.4. [244]Hardware Flow Control
+9.5. [245]Terminal Speeds
+9.6. [246]Millisecond Sleeps
+9.7. [247]Nondestructive Input Buffer Peeking
+9.8. [248]Other System-Dependent Features
+9.9. [249]Terminal Interruption
There are several major varieties of Unix: Bell Laboratories Seventh
Edition, AT&T System V, Berkeley Standard Distribution (BSD), and
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.
+ 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
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!
+ 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>
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).
+ like this, dirty tricks are the only recourse (search for SCO_OSR504 in
+ [250]ckutio.c for examples).
For reasons like this, Unix implementations tend to be neither pure
AT&T nor pure BSD nor pure POSIX, but a mixture of two or more of
these, with "compatibility features" allowing different varieties of
- programs to be built on the same computer. In general, Kermit tries
- not to mix and match but to keep a consistent repertoire throughout.
- However, there are certain Unix implementations that only work when
- you mix and match. For example, the Silicon Graphics IRIX operating
- system (prior to version 3.3) is an AT&T Unix but with a BSD file
- system. The only way you can build Kermit successfully for this
- configuration is to include -DSVR3 plus the special option -DLONGFN,
- meaning "pretend I was built with -DBSDxx when it's time to compile
- file-related code". See the "iris" makefile target.
- ________________________________________________________________________
+ 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
+9.1. Standards
- [ [237]Top ] [ [238]Section Contents ] [ [239]Contents ] [ [240]Next ]
+ [ [251]Top ] [ [252]Section Contents ] [ [253]Contents ] [ [254]Next ]
SUBSECTION CONTENTS
-9.1.1. [241]POSIX
-9.1.2. [242]ANSI C
-9.1.3. [243]Other Standards
+9.1.1. [255]POSIX
+9.1.2. [256]ANSI C
+9.1.3. [257]Other Standards
In edits 166-167 (1988-89), C-Kermit was heavily modified to try to
- keep abreast of new standards while still remaining compatible with
- old versions of C and Unix. There are two new standards of interest:
- ANSI C (as described in Kernighan and Ritchie, "The C Programming
- Language", Second Edition, Prentice Hall, 1988) and POSIX.1 (IEEE
- Standard 1003.1 and ISO/IEC 9945-1, 1990, "Portable Operating System
- Interface"). These two standards have nothing to do with each other:
- you can build C-Kermit with a non-ANSI compiler for a POSIX system, or
- for a non-POSIX system with with an ANSI compiler.
+ 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
+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
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
+ 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
(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:
+ 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"
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
+ 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 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.
+ 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().
"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.
+ 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
+ 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.
+ 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.
+ 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
+ incompatible thread APIs. We have POSIX and DCE, they have POSIX and
+ UI. The nasty areas are in the _r routines and in some aspects of
+ signal behavior. You cannot compile a single source file that uses
+ both semantics. That's life. It sounds as if Solaris defaults to the
+ UI variants, but allows you to define this _POSIX_THREAD_SEMANTICS
+ to get around it. We default to POSIX, and allow you to define
+ _PTHREAD_USE_D4 (automatically defined by the cc "-threads" switch)
+ to select the DCE thread variants. That default, because you're
+ operating outside of any individual standard, is really just a
+ marketing decision.
+
+9.1.2. ANSI C
+
+ [ [258]Top ] [ [259]Contents ] [ [260]Section Contents ] [
+ [261]Subsection Contents ] [ [262]Next ] [ [263]Previous ]
+
+ The major difference between ANSI C and earlier C compilers is function
+ prototyping. ANSI C allows function arguments to be checked for type
+ agreement, and (when possible) type coercion in the event of a
+ mismatch. For this to work, functions and their arguments must be
declared before they are called. The form for function declarations is
different in ANSI C and non-ANSI C (ANSI C also accepts the earlier
form, but then does not do type checking).
internally.
On the downside, ANSI C compilation increases the
- administrative/bureacratic burden, spewing out countless unneeded
+ administrative/bureaucratic 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.
+ 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.
- ______________________________________________________________________
+ 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
+9.1.3. Other Standards
- [ [250]Top ] [ [251]Contents ] [ [252]Section Contents ] [
- [253]Subsection Contents ] [ [254]Next ] [ [255]Previous ]
+ [ [264]Top ] [ [265]Contents ] [ [266]Section Contents ] [
+ [267]Subsection Contents ] [ [268]Next ] [ [269]Previous ]
As the years go by, standards with-which-all-must-comply continue to
pile up: AES, XPG2, XPG3, XPG4, FIPS 151-2, successive generations of
POSIX, OSF/1, X/Open, Spec 1170, UNIX95, Open Group UNIX98, ISO/IEC
9945 parts 1-4, ISO 9899, 88Open, OS 99, Single Unix Specification
- (SUS, [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.
+ (SUS, [270]IEEE 1003.1-2001, not to mention "mature standards" like V7,
+ 4.2/4.3BSD, System V R3 and R4 (SVID2 and SVID3), 4.4BSD (the basis for
+ BSDI, OpenBSD, NetBSD, FreeBSD, Mac OS X etc), /usr/group, plus
+ assorted seismic pronouncements of the neverending series of ephemeral
+ corporate consortia, not to mention the libc-vs-glibc turmoil in the
+ Linux arena and who knows what else.
None of these standards simplifies life for portable applications like
C-Kermit -- each one is simply one more environment to support (or
circumvent, as in many cases these standards do more harm than good by
- denying access to facilities we need, e.g. as noted in above in
- [257]9.1.1).
- ________________________________________________________________________
+ denying accesss to facilities we need, e.g. as noted in above in
+ [271]9.1.1).
- 9.2. Library Issues
+9.2. Library Issues
- [ [258]Top ] [ [259]Contents ] [ [260]Section Contents ] [
- [261]Subsection Contents ] [ [262]Next ] [ [263]Previous ]
+ [ [272]Top ] [ [273]Contents ] [ [274]Section Contents ] [
+ [275]Subsection Contents ] [ [276]Next ] [ [277]Previous ]
On most modern platforms, applications are -- and often must be --
dynamically linked. This has numerous advantages (smaller executables,
ability to patch a library and thereby patch all applications that use
- it, etc), but also causes some headaches: most commonly, the library
- ID built into the executable at link time does not match the ID of the
+ 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.
+ 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!
- ________________________________________________________________________
+ 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
+9.3. Unix File System Peculiarities
- [ [264]Top ] [ [265]Contents ] [ [266]Section Contents ] [ [267]Next ]
- [ [268]Previous ]
+ [ [278]Top ] [ [279]Contents ] [ [280]Section Contents ] [ [281]Next ]
+ [ [282]Previous ]
Normally, including a BSD, System-V, POSIX, or DIRENT flag in the make
- entry selects the right file system code. But some versions of Unix
- are inconsistent in this regard, and building in the normal way either
+ 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
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:
+ Graphics IRIX, and perhaps also MIPS. In this case, try adding -DLONGFN
+ to your makefile target.
+
+ Another problem child is <sys/file.h>. Most Unix C-Kermit versions need
+ to #include this file from within [283]ckufio.c and [284]ckutio.c, but
+ some not only do not need to include it, but MUST not include it
+ because (a) it doesn't exist, or (b) it has already been included by
+ some other header file and it doesn't protect itself against multiple
+ inclusion, or (c) some other reason that prevents successful
+ compilation. If you have compilation problems that seem to stem from
+ including this file, then add the following switch to CFLAGS in your
+ makefile target:
-DNOFILEH
- There are a few odd cases where <sys/file.h> must be included in one
- of the cku[ft]io.c files, but not the other. In that case, add the
- aforementioned switch, but go into the file that needs <sys/file.h>
- and add something like this:
+ 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
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:
+ (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
* 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
+ 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.
- ________________________________________________________________________
+ code in zstrdt() in [285]ckufio.c.
- 9.4. Hardware Flow Control
+9.4. Hardware Flow Control
- [ [272]Top ] [ [273]Contents ] [ [274]Section Contents ] [ [275]Next ]
- [ [276]Previous ]
+ [ [286]Top ] [ [287]Contents ] [ [288]Section Contents ] [ [289]Next ]
+ [ [290]Previous ]
Hardware flow control is a problematic concept in many popular Unix
implementations. Often it is lacking altogether, and when available,
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:
+ b. RTS/CTS flow control support MIGHT be available for System V R3 and
+ later if /usr/include/termiox.h exists (its successful operation
+ also depends on the device driver, and the device itself, not to
+ mention the [291]cable, etc, actually supporting it). If your
+ SVR3-or-later Unix system does have this file, add:
-DTERMIOX
-DSTERMIOX
- Note that the presence of this file does not guarantee that
- RTS/CTS will actually work -- that depends on the device-driver
+ 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).
+ 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)
+ 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
+ See the routine tthflow() in [292]ckutio.c for details. If you find
that your system offers hardware flow control selection under program
control, you can add this capability to C-Kermit as follows:
- a. See if it agrees with one of the methods already used in
- tthflow(). if not, add new code, appropriately #ifdef'd.
+ 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.
+ define this symbol within the appropriate #ifdefs in [293]ckcdeb.h.
To illustrate the difficulties with RTS/CTS, here is a tale from Jamie
Watson <jw@adasoft.ch>, who added the RTS/CTS code for the RS/6000,
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."
- ________________________________________________________________________
+ 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 ]
+ [ [294]Top ] [ [295]Contents ] [ [296]Section Contents ] [ [297]Next ]
+ [ [298]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
+ [299]ckcdeb.h. If your system supports speeds that are not listed in
"set speed ?", you can add definitions for them to ckcdeb.h.
Then if the speed you are adding is one that was never used before in
Kermit, such as 921600, you'll also need to add the appropriate
- keywords to spdtab[] in [285]ckuus3.c, and the corresponding case to
- ttsspd() in [286]ckutio.c.
- ________________________________________________________________________
+ keywords to spdtab[] in [300]ckuus3.c, and the corresponding case to
+ ttsspd() in [301]ckutio.c.
9.6. Millisecond Sleeps
- [ [287]Top ] [ [288]Contents ] [ [289]Section Contents ] [ [290]Next ]
- [ [291]Previous ]
+ [ [302]Top ] [ [303]Contents ] [ [304]Section Contents ] [ [305]Next ]
+ [ [306]Previous ]
There is no standard for millisecond sleeps, but at least five
different functions have appeared in various Unix versions that can be
-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.
+ 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
compile-time option:
-DNAPHACK
- ________________________________________________________________________
9.7. Nondestructive Input Buffer Peeking
- [ [292]Top ] [ [293]Contents ] [ [294]Section Contents ] [ [295]Next ]
- [ [296]Previous ]
+ [ [307]Top ] [ [308]Contents ] [ [309]Section Contents ] [ [310]Next ]
+ [ [311]Previous ]
Some AT&T Unix versions have no way to check if input is waiting on a
tty device, but this is a very important feature for Kermit. Without
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:
+ 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:
+ Conversely, if the build procedure tries to use select() when it really
+ is not there, add:
-DNOSELECT
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 ]
+ [ [312]Top ] [ [313]Contents ] [ [314]Section Contents ] [ [315]Next ]
+ [ [316]Previous ]
Systems with <termios.h> might have the symbol IEXTEN defined. This is
used to turn "extended features" in the tty device driver on and off,
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
+ operation, so if [317]ckutio.c finds this symbol, it uses it. This is
necessary, at least, on BSDI. On some systems, however, IEXTEN is
- either misdefined or misimplemented. The symptom is that CR, when
- typed to the command processor, is echoed as LF, rather than CRLF.
- This happens (at least) on Convex/OS 9.1. The solution is to add the
+ 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
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:
+ writing" phenomenon during interactive command parsing. This was traced
+ to a setbuf() call in [318]ckutio.c that made console (stdout) writes
+ unbuffered. This setbuf() call has been there forever, and could not be
+ removed without some risk. Kermit's operation was tested on the NeXT in
+ edit 178 with the setbuf() call removed, and the slow-writing symptom
+ was cured, and everything else (command parsing, proper wakeup on ?,
+ ESC, Ctrl-U, and other editing characters, terminal emulation,
+ remote-mode and local-mode file transfer, etc) seemed to work as well
+ as or better than before. In subsequent edits, this change was made to
+ many other versions too, with no apparent ill effects. To remove the
+ setbuf() call for your version of Kermit, add:
-DNOSETBUF
Later reports indicate that adding -DNOSETBUF has other beneficial
effects, like cutting down on swapping when Kermit is run on
workstations with small memories. But BEWARE: on certain small Unix
- systems, notably the AT&T 6300 and 3B1 (the very same ones that
- benefit from NOSETBUF), NOSETBUF seems to conflict with CK_CURSES. The
- program builds and runs OK, but after once using the curses display,
- echoing is messed up. In this case, we use a System-V specific
- variation in the curses code, using newterm() to prevent System V from
- altering the buffering. See makefile entries for AT&T 6300 and 3B1.
-
- The Unix version of C-Kermit includes code to switch to file
- descriptor zero (stdin) for remote-mode file transfer. This code is
- necessary to prevent Kermit from giving the impression that it is
- "idle" during file transfers, which, at some sites, can result in the
- job being logged out in the middle of an active file transfer by
- idle-job monitors.
+ 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.
+ 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:
+ 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
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:
+ 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
-DRENAME
C-Kermit predefines the RENAME for several Unix versions in
- [304]ckcdeb.h (SVR4, SUNOS41, BSD44, AIXRS, etc). You can tell if
+ [319]ckcdeb.h (SVR4, SUNOS41, BSD44, AIXRS, etc). You can tell if
rename() is being used if the SHOW FEATURES command includes RENAME in
the compiler options list. If the predefined RENAME symbol causes
trouble, then add NORENAME to your CFLAGS. Trouble includes:
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
+ automatically in [320]ckufio.c. Other systems might have this same
problem. If you get a compile-time error message regarding S_ISREG
and/or S_ISDIR, add the following to your CFLAGS:
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 ]
+ [ [321]Top ] [ [322]Contents ] [ [323]Section Contents ] [ [324]Next ]
+ [ [325]Previous ]
When C-Kermit enters interactive command mode, it sets a Control-C
(terminal keyboard interrupt = SIGINT) trap to allow it to return to
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.
+ 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.)
+ 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
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:
+ 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
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.
+ [ [326]Top ] [ [327]Contents ] [ [328]Next ] [ [329]Previous ]
- The short version:
+ The short version (general):
In order for C-Kermit to be able to dial out from your Unix
- computer, you need to give it the same owner, group, and
- permissions as your other dialout programs, such as cu, tip,
- minicom, uucp, seyon, etc.
+ computer, you need to give it the same owner, group, and permissions
+ as your other dialout programs, such as cu, tip, minicom, uucp,
+ seyon, etc.
+
+ The short version for Linux only:
+
+ Since Red Hat 7.2, about 2002, Linux does not leave the lockfile
+ handling to each application, but instead provides an external
+ application, /usr/sbin/lockdev, that all applications should invoke
+ when they need to accesss a serial port; lockdev locks and unlocks
+ the port without requiring the application to have privileges, since
+ the privileges on the lockfile directory are assigned to lockdev.
+ C-Kermit 8.0.211 and later support this method. But C-Kermit still
+ needs to be able to open the port itself, and therefore if the
+ port's permissions do not allow read/write accesss to the general
+ public, the general rule must still be followed: in the most common
+ case, it must be SETGID to the group uucp (explained below). If a
+ pre-8.0.211 version of C-Kermit is to be installed for use with
+ serial ports on any version of Linux, it must still be installed as
+ described in the following sections.
The long version:
- Make sure your dialout line is correctly configured for dialing out
- (as opposed to login). The method for doing this is different for each
- kind of Unix. Consult your system documentation for configuring lines
- for dialing out (for example, Sun SPARCstation IPC users should read
- the section "Setting up Modem Software" in the Desktop SPARC Sun
- System and Network Manager's Guide, or the Terminals and Modems
- section of the HP manual, "Configuring HP-UX for Peripherals" (e.g.
- /usr/sbin/sam => Peripheral Devices => Terminals and Modems => Add
- Modem).
+ 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
+ allows multiple users to accesss 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).
+ see them all. Furthermore, User B can hang up User A's call, and so
+ one.
+
+ Rather than change Unix to enforce exclusive accesss to serial devices
+ such as ttys, when it might still have been possible, Unix developers
+ opted for a "lock file" mechanism. Any process that wants to open a tty
+ device should first check to see if a file of a certain name exists,
+ and if so, not to open the device. If the file does not exist, the
+ process creates the file and then opens the device. When the process
+ closes the device, it destroys the lockfile. This procedure was
+ originated for use with Unix's UUCP, CU, and TIP programs, and so these
+ lockfiles are commonly called "UUCP lockfiles" (UUCP = Unix-to-Unix
+ Copy Program).
As you can imagine, this method is riddled with pitfalls:
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.
+ 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.
+ * 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.
+ 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:
+ 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
* 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
+ improperly taken as valid, and accesss 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,
+ * 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.
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.
+ 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
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
+ To fit in with UUCP and other Unix-based serial-port communication
+ software, C-Kermit must have the same idea as your system's uucp, cu,
+ and tip programs about what the UUCP lock directory is called, what the
lockfile itself is called, and what its contents should be. In most
- cases, C-Kermit preprocessor flags create the appropriate
- configuration at compile time if the appropriate makefile target was
- used (see [315]ckutio.c). The following CFLAGS options can be used to
- override the built-in configuration:
+ cases, C-Kermit preprocessor flags create the appropriate configuration
+ at compile time if the appropriate makefile target was used (see
+ [330]ckutio.c). The following CFLAGS options can be used to override
+ the built-in configuration:
-DLCKDIR
Tells Kermit that the UUCP lock directory is
when done.
-DHDBUUCP
- Include this if your system uses Honey DanBer UUCP, in which
- the lockfile directory and format are relatively standardized.
+ 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
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.
+ prevent another user from simultaneously 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,
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:
+ 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.
+ 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
NOTE: symlinks are not handled in HP-UX.
- Honey DanBer (HDB) UUCP, which is becoming increasingly popular, has
+ Honey DanBer (HDB) UUCP, the basis of many UUCP implementations, has
two characteristics:
a. Lockfiles are kept in /usr/spool/locks/ (usually).
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.
+ (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:
+ 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
+ b. "Sorry, accesss 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 "accesss 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 guarantee 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, accesss 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.
+ 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):
+ 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
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:
+ b. Use groups to regulate accesss. 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:
+ the appropriate group (e.g. edit the /etc/group file).
+ c. Have the superuser change Kermit to run setuid and/or setgid to the
+ owner and/or group of the lockfile directory and the tty devices if
+ necessary), typically uucp (see [331]next section), but NOT root.
+ Example:
su% chown uucp kermit - or - chgrp uucp kermit
su% chmod u+s kermit (setuid) - or - chmod g+s kermit (setgid)
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
+ is that read/write accesss 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:
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
+ requires suid uucp to get read/write accesss on /dev/cua3 and sgid to
+ get read/write accesss 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:
+ 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 accesss files like
+ Kermit does.)
+
+ For the lockfile mechanism to achieve its desired purpose -- prevention
+ of accesss 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:
+ lockfile directory just for Kermit, for example, /usr/spool/kermit,
+ and make sure you have read/write accesss to it. Then add the
+ following to your makefile target CFLAGS, as shown earlier:
-DLOCK_DIR=\\\"/usr/spool/kermit\\\"
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 ]
+ [ [332]Top ] [ [333]Contents ] [ [334]Next ] [ [335]Previous ]
Even if you don't intend to run C-Kermit setuid, somebody else might
come along and chown and chmod it after it has been built. You should
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
+ 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.
+ 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.
+ 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.
+ 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.
+ [336]ckutio.c.
- If you have a version of Unix that is not BSD-based, but which
- supplies the setreuid() and setregid() functions, and these are the
- only way to switch between real and effective uid, add -DSETREUID to
- your makefile target.
+ 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
+ WARNING: There are two calls to accesss() in [337]ckufio.c, by which
Kermit checks to see if it can create an output file. These calls
will not work correctly when (a)you have installed C-Kermit setuid
or setgid on a BSD-based Unix system, and (b) the
- saved-original-effective-uid/gid feature is not present, and (c)
- the access() function always checks what it believes to be the real
- ID rather than the effective ID. This is the case, for example, in
+ saved-original-effective-uid/gid feature is not present, and (c) the
+ accesss() 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
+ operation of accesss() 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
+ 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
+ with exclusive accesss only, enforced by the Unix kernel. Shared
+ accesss 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
+ 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
+ making the simple kernel change required to enforce exclusive accesss
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.)
- __________________________________________________________________________
+ 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 ]
+ [ [338]Top ] [ [339]Contents ] [ [340]Next ] [ [341]Previous ]
On desktop workstations that are used by only the user at the console
keyboard, C-Kermit is always used in local mode. But as delivered,
C-Kermit runs in remote mode by default. To put it in local mode at
startup, you can put a SET LINE command in your .mykermrc.
- You can also build C-Kermit to start up in local mode by default. To
- do this, include the following in the CFLAGS in your makefile target:
+ 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\\\"
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 ]
+ [ [342]Top ] [ [343]Contents ] [ [344]Next ] [ [345]Previous ]
See the "beware file",
- [331]ckubwr.txt, for hints about runtime misbehavior. This section
+ [346]ckubwr.txt, for hints about runtime misbehavior. This section
lists some runtime problems that can be cured by rebuilding C-Kermit.
The program starts, but there is no prompt, and certain operations
don't work (you see error messages like "Kermit command error in
background execution"). This is because Kermit thinks it is running in
- the background. See conbgt() in [332]ckutio.c. Try rebuilding Kermit
+ the background. See conbgt() in [347]ckutio.c. Try rebuilding Kermit
with:
-DPID_T=pid_t
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
+ 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
+ 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 ]
+ [ [348]Top ] [ [349]Contents ] [ [350]Next ] [ [351]Previous ]
- If C-Kermit constitently dumps core at the beginning of a file
+ If C-Kermit consistently 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).
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.
+ 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:
+ 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.
+ 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
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.
+ 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 ]
+ [ [352]Top ] [ [353]Contents ] [ [354]Next ] [ [355]Previous ]
- "Syslogging" means recording selected in the system log via the Unix
- syslog() facility, which is available in most Unix versions.
+ "Syslogging" means recording selected information in the system log via
+ the Unix syslog() facility, which is available in most Unix versions.
Syslogging is not done unless C-Kermit is started with:
--syslog:n
- on the command-line, where n is a number greater than 0 to indicate
- the level of syslogging. See [341]Section 4.2 of the [342]IKSD
+ on the command-line, where n is a number greater than 0 to indicate the
+ level of syslogging. See [356]Section 4.2 of the [357]IKSD
Administrator's Guide for details.
- Obviously you can't depend on users to include --syslog:3 (or
- whatever) on the command line every time they start C-Kermit, so if
- you want certain kinds of records to be recorded in the system log,
- you can build C-Kermit with forced syslogging at the desired level,
- e.g.:
+ Obviously you can't depend on users to include --syslog:3 (or whatever)
+ on the command line every time they start C-Kermit, so if you want
+ certain kinds of records to be recorded in the system log, you can
+ build C-Kermit with forced syslogging at the desired level; for
+ example, to record logins and dialouts:
make linux KFLAGS=-DSYSLOGLEVEL=2
- Levels 2 and 3 are the most likely candidates for this treatment.
- Level 2 forces logging of all successful dialout calls (e.g. for
- checking against or phone bills), and level 3 records all connections
- (SET LINE or SET HOST / TELNET / RLOGIN, etc) so you can see who is
- connecting out from your system, and to where.
+ Levels 2 and 3 are the most likely candidates for this treatment. Level
+ 2 forces logging of all successful dialout calls (e.g. for checking
+ against or phone bills), and level 3 records all connections (SET LINE
+ or SET HOST / TELNET / RLOGIN, etc) so you can see who is connecting
+ out from your system, and to where, e.g. for security auditing.
Level 2 and 3 records are equivalent to those in the connection log;
- see the [343]C-Kermit 7.0 Supplement) for a detailed description of
- the connection log.
- __________________________________________________________________________
+ see the [358]C-Kermit 7.0 Supplement) for a detailed description of the
+ connection log.
16. BUILDING SECURE VERSIONS OF C-KERMIT 8.0
- [ [344]Top ] [ [345]Contents ] [ [346]Next ] [ [347]Previous ]
+ [ [359]Top ] [ [360]Contents ] [ [361]Next ] [ [362]Previous ]
C-Kermit 7.0 and later may be built with Kerberos(TM) and/or SRP(TM)
(Secure Remote Password) and/or SSL/TLS security for strong
authentication and encryption of Internet connections. These security
methods require external libraries that, in their binary forms, are
- restricted from export by USA law. See the [348]Kermit Security
+ restricted from export by USA law. See the [363]Kermit Security
Reference) for details. C-Kermit binaries themselves are likewise
restricted; the C-Kermit binaries that are available for public
download on the Internet are not allowed to contain the security
options.
- Sample makefile entries are provided for Linux and many other
- operating systems. A list of secure makefile entries is included in
- the Makefile. Complete instructions on building C-Kermit 8.0 with MIT
- Kerberos; Secure Remote Password; and/or OpenSSL can be found in the
- [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
- __________________________________________________________________________
+ Sample makefile entries are provided for Linux and many other operating
+ systems. A list of secure makefile entries is included in the Makefile.
+ Complete instructions on building C-Kermit 8.0 with MIT Kerberos;
+ Secure Remote Password; and/or OpenSSL can be found in the [364]Kermit
+ Security Reference.
+
+ SSL/TLS and Kerberos builds are increasingly problematic with the
+ "deprecation" of DES. There is code to detect the presence or absence
+ of DES in the OpenSSL builds, but it doesn't always work because
+ sometimes the SSL libraries are present but routines are missing from
+ them.
+
+ * First of all remember that if your SSL and/or Kerberos header files
+ and libraries are not in the default place, you'll need to override
+ the assumed paths. To find out what the default places are type
+ "make show", e.g.:
+
+[~/kermit] make show
+prefix=/usr/local
+srproot=/usr/local
+sslroot=/usr/local
+manroot=/usr/local
+K4LIB=-L/usr/kerberos/lib
+K4INC=-I/usr/kerberos/include
+K5LIB=-L/usr/kerberos/lib
+K5INC=-I/usr/kerberos/include
+SRPLIB=-L/usr/local/lib
+SRPINC=-I/usr/local/include
+SSLLIB=-L/usr/local/ssl/lib
+SSLINC=-I/usr/local/ssl/include
+[~/kermit]
+
+ * You can override any or all of these by putting assignments on the
+ 'make' command line; examples:
+
+make linux+krb5 \
+ "K5INC=-I/usr/include/" \
+ "K5LIB=-L/usr/lib64/"
+
+make solaris9g+ssl \
+ "SSLLIB=-L/opt/openssl-0.9.8q/lib" \
+ "SSLINC=-I/opt/openssl-0.9.8q/include"
+
+ Or by setting and exporting environment variables prior to giving
+ the 'make' command, as in this example in which (after Beta.01 was
+ uploaded) C-Kermit was successfully linked with OpenSSL 1.0.0d,
+ which was installed alongside OpenSSL 0.9.8r on the same computer.
+ Note the use of the '-i' option instead of '-I' to force gcc to
+ include the right header files (thanks to Nelson Beebe for this):
+
+export PATH=/usr/bin:$PATH
+export SSLINC=-isystem/usr/include
+export "SSLLIB=-L/usr/lib -Wl,-rpath,/usr/lib"
+make linux+ssl
+
+ -i is explained in 'man gcc'; there is a change in what -I does
+ that could have ramifications for many makefile targets, not just
+ Kermit. And -Wl and -rpath are explained in 'man ld'; the idea is
+ build a binary from which useful reports can be obtained with ldd.
+ * Building with OpenSSL versions prior to 0.9.7 doesn't work, even
+ though C-Kermit is designed to work with both the old and new
+ versions. This could probably be fixed if anybody cares.
+ * If a Kerberos or SSL build fails at link time because
+ des_ecb3_encrypt, des_random_seed, and/or des_set_odd_parity come
+ up missing, redo the build with -UCK_DES:
+
+make netbsd+krb5+ssl \
+ "K5INC=-I/usr/local/include" \
+ "K5LIB=-L/usr/local/kerblib" KFLAGS=-UCK_DES
+
+ I suppose all the SSL and Kerberos targets could be recoded to
+ figure this out automatically (i.e. that DES is installed but with
+ some entry points missing), but it wouldn't be pretty.
+ * Different Kerberos and OpenSSL distributions can be installed with
+ different options; certain libraries might be missing or named
+ differently (for example, libgssapi vs libgssapi_krb5). Some, but
+ not all, of the C-Kermit makefile targets have been fixed to take
+ some of these variations into account by testing for them, most
+ notably the linux ones, linux+ssl, linux+krb5, and linux+krb5+ssl.
+ Probably every target that builds with OpenSSL or Kerberos needs
+ the same treatment but I won't have time.
+ * Why doesn't C-Kermit just use Autoconf? Mainly because the makefile
+ is full of targets for platforms that don't have Autoconf or any
+ other tool like it. (Another reason is that I've always preferred
+ that Kermit have the least dependencies possible on external
+ toolsets.) Perhaps certain targets could be converted to use them,
+ especially Linux because there are so many variations among
+ distributions and versions. Anybody who wants to make, say, an
+ Autonf-based Linux target, be my guest, but bear in mind that one
+ Linux target is supposed to work for all versions and distributions
+ of Linux on all platforms. Well, one target for Linux by itself,
+ another for Linux with OpenSSL, another for Linux with Kerberos 5,
+ and another for Linux with Kerberos 5 and OpenSSL. Each of these is
+ supposed to work on any Linux version with any version of
+ Kerberos 5 or OpenSSL.
+
+ Also note that Kerberos support is for the MIT version only, Heimdal
+ and others are not supported (never have been). Of course anybody can
+ pitch in and add or improve support for whatever they want.
17. INSTALLING C-KERMIT AS AN SSH SERVER SUBSYSTEM
- [ [352]Top ] [ [353]Contents ] [ [354]Previous ]
+ [ [365]Top ] [ [366]Contents ] [ [367]Previous ]
This requires C-Kermit 8.0.206 or later and an SSH v2 server. If you
list C-Kermit as a Subsystem in the SSH v2 server configuration file
(as, for example, SFTP is listed), users can make SSH connections
direct to a Kermit server as explained here:
-[355]http://www.columbia.edu/kermit/skermit.html
+[368]http://www.columbia.edu/kermit/skermit.html
The name and location of the SSH server configuration file depends on
- your platform, which SSH product(s) you have, etc. C-Kermit itself
- must be referred to in this file as "kermit-sshsub". On the host,
- install the C-Kermit 8.0.211 binary in the normal way. Then, in the
- same directory as the C-Kermit binary, make a symbolic link:
+ 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
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.
+ is.) This is similar to the line that sets up the SFTP subsystem.
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.
+ 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 ]
- _________________________________________________________________
+ [ [369]Top ] [ [370]Contents ] [ [371]C-Kermit Home ] [ [372]C-Kermit
+ 9.0 Overview ] [ [373]Kermit Home ]
+ __________________________________________________________________
- C-Kermit 8.0 Unix Installation Instructions / The Kermit Project /
- Columbia University / 10 April 2004
+ C-Kermit 9.0 Unix Installation Instructions / The Kermit Project /
+ Columbia University / 30 June 2011
References
- 1. http://www.columbia.edu/kermit/ckuins.html#contents
- 2. http://www.columbia.edu/kermit/ckermit.html
+ 1. http://www.columbia.edu/
+ 2. mailto:kermit@columbia.edu
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
+ 4. http://www.columbia.edu/kermit/k95.html
+ 5. http://www.columbia.edu/kermit/ckermit.html
+ 6. http://www.columbia.edu/kermit/ckscripts.html
+ 7. http://www.columbia.edu/kermit/current.html
+ 8. http://www.columbia.edu/kermit/whatsnew.html
+ 9. http://www.columbia.edu/kermit/faq.html
+ 10. http://www.columbia.edu/kermit/support.html
+ 11. http://www.columbia.edu/kermit/ckuins.html#contents
+ 12. http://www.columbia.edu/kermit/ckermit.html
+ 13. http://www.columbia.edu/kermit/index.html
+ 14. http://www.columbia.edu/kermit/ckuins.html
+ 15. http://www.columbia.edu/kermit/ckuins.html#x0
+ 16. http://www.columbia.edu/kermit/ckuins.html#x1
+ 17. http://www.columbia.edu/kermit/ckuins.html#x2
+ 18. http://www.columbia.edu/kermit/ckuins.html#x3
+ 19. http://www.columbia.edu/kermit/ckuins.html#x4
+ 20. http://www.columbia.edu/kermit/ckuins.html#x5
+ 21. http://www.columbia.edu/kermit/ckuins.html#x6
+ 22. http://www.columbia.edu/kermit/ckuins.html#x7
+ 23. http://www.columbia.edu/kermit/ckuins.html#x8
+ 24. http://www.columbia.edu/kermit/ckuins.html#x9
+ 25. http://www.columbia.edu/kermit/ckuins.html#x10
+ 26. http://www.columbia.edu/kermit/ckuins.html#x11
+ 27. http://www.columbia.edu/kermit/ckuins.html#x12
+ 28. http://www.columbia.edu/kermit/ckuins.html#x13
+ 29. http://www.columbia.edu/kermit/ckuins.html#x14
+ 30. http://www.columbia.edu/kermit/ckuins.html#x15
+ 31. http://www.columbia.edu/kermit/ckuins.html#x16
+ 32. http://www.columbia.edu/kermit/ckuins.html#x17
33. http://www.columbia.edu/kermit/ckuins.html#top
34. http://www.columbia.edu/kermit/ckuins.html#contents
- 35. http://www.columbia.edu/kermit/ckuins.html#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
+ 35. http://www.columbia.edu/kermit/ckuins.html#x1
+ 36. http://www.columbia.edu/kermit/ckccfg.html
+ 37. http://www.columbia.edu/kermit/ckcbwr.html
+ 38. http://www.columbia.edu/kermit/ckubwr.html
+ 39. http://www.columbia.edu/kermit/ckcplm.html
+ 40. http://www.columbia.edu/kermit/ckuins.html#x2
+ 41. http://www.columbia.edu/kermit/ckuins.html#x3
+ 42. http://www.columbia.edu/kermit/ckuins.html#x4
+ 43. http://www.columbia.edu/kermit/ckuins.html#top
+ 44. http://www.columbia.edu/kermit/ckuins.html#contents
+ 45. http://www.columbia.edu/kermit/ckuins.html#x2
+ 46. http://www.columbia.edu/kermit/ckuins.html#x0
+ 47. ftp://www.columbia.edu/kermit/archives/cku211.tar.Z
+ 48. ftp://www.columbia.edu/kermit/archives/cku211.tar.gz
+ 49. http://kermit.columbia.edu/ftp/archives/cku211.tar.Z
+ 50. http://kermit.columbia.edu/ftp/archives/cku211.tar.gz
+ 51. ftp://www.columbia.edu/kermit/archives/cku211.tar
+ 52. http://kermit.columbia.edu/ftp/archives/cku211.tar
+ 53. http://www.columbia.edu/kermit/ckuins.html#x7
+ 54. http://www.columbia.edu/kermit/ckuins.html#x5
+ 55. http://www.columbia.edu/kermit/ckuins.html#x5
+ 56. http://www.columbia.edu/kermit/ckuins.html#x16
+ 57. http://www.columbia.edu/kermit/ckuins.html#top
+ 58. http://www.columbia.edu/kermit/ckuins.html#contents
+ 59. http://www.columbia.edu/kermit/ckuins.html#x3
+ 60. http://www.columbia.edu/kermit/ckuins.html#x1
+ 61. http://www.columbia.edu/kermit/ckuins.html#x5
+ 62. http://www.columbia.edu/kermit/ckuins.html#X10
+ 63. http://www.columbia.edu/kermit/ckuins.html#x11
+ 64. http://www.columbia.edu/kermit/ckuins.html#x10
+ 65. http://www.columbia.edu/kermit/ckuins.html#x3
+ 66. http://www.columbia.edu/kermit/ck80packages.html
+ 67. http://www.columbia.edu/kermit/ckuins.html#x10
+ 68. http://www.columbia.edu/kermit/ckuins.html#top
+ 69. http://www.columbia.edu/kermit/ckuins.html#contents
+ 70. http://www.columbia.edu/kermit/ckuins.html#x4
+ 71. http://www.columbia.edu/kermit/ckuins.html#x2
+ 72. ftp://www.columbia.edu/kermit/bin/
+ 73. http://www.columbia.edu/kermit/ck80binaries.html
+ 74. http://www.columbia.edu/kermit/ckuins.html#x7
+ 75. http://www.columbia.edu/kermit/ckuins.html#build
76. http://www.columbia.edu/kermit/ckuins.html#x5
- 77. 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
+ 77. http://www.columbia.edu/kermit/ckuins.html#x4
+ 78. http://www.columbia.edu/kermit/ckfaq.html#version
+ 79. http://www.columbia.edu/kermit/ckuins.html#x4
+ 80. mailto:kermit@columbia.edu
+ 81. http://www.columbia.edu/kermit/ckuins.html#top
+ 82. http://www.columbia.edu/kermit/ckuins.html#contents
+ 83. http://www.columbia.edu/kermit/ckuins.html#x5
+ 84. http://www.columbia.edu/kermit/ckuins.html#x3
+ 85. http://www.columbia.edu/kermit/ckuins.html#x8
+ 86. http://www.columbia.edu/kermit/ckuins.html#x9
+ 87. ftp://kermit.columbia.edu/kermit/c-kermit/makefile
+ 88. ftp://kermit.columbia.edu/kermit/c-kermit/ckpker.mk
+ 89. ftp://kermit.columbia.edu/kermit/c-kermit/ckubsd.mak
+ 90. http://www.columbia.edu/kermit/ckuins.html#x5
+ 91. mailto:kermit-support@columbia.edu
+ 92. ftp://kermit.columbia.edu/kermit/c-kermit/makefile
+ 93. http://www.columbia.edu/kermit/ckuins.html#x7
+ 94. mailto:kermit-support@columbia.edu
+ 95. ftp://kermit.columbia.edu/kermit/c-kermit/makefile
+ 96. http://www.columbia.edu/kermit/ckuins.html#x5.4
+ 97. http://www.columbia.edu/kermit/ckuins.html#x10
+ 98. http://www.columbia.edu/kermit/ckuins.html#x11
+ 99. http://www.columbia.edu/kermit/ckuins.html#x5
+ 100. http://www.columbia.edu/kermit/iksd.html
+ 101. http://www.columbia.edu/kermit/ckuins.html#top
+ 102. http://www.columbia.edu/kermit/ckuins.html#contents
+ 103. http://www.columbia.edu/kermit/ckuins.html#x4.1
+ 104. http://www.columbia.edu/kermit/ckccfg.html
+ 105. http://www.columbia.edu/kermit/ckuins.html#x4.1
+ 106. http://www.columbia.edu/kermit/ckuins.html#x4.2
+ 107. http://www.columbia.edu/kermit/ckuins.html#x4.3
+ 108. http://www.columbia.edu/kermit/ckuins.html#x4.4
+ 109. http://www.columbia.edu/kermit/ckuins.html#x4.5
+ 110. http://www.columbia.edu/kermit/ckccfg.html
+ 111. http://www.columbia.edu/kermit/ckccfg.html#x8
+ 112. http://www.columbia.edu/kermit/iksd.html
+ 113. http://www.columbia.edu/kermit/iksd.html
+ 114. ftp://kermit.columbia.edu/kermit/c-kermit/ckufio.c
+ 115. ftp://kermit.columbia.edu/kermit/c-kermit/ckufio.c
+ 116. mailto:kermit-support@columbia.edu
+ 117. ftp://kermit.columbia.edu/kermit/c-kermit/ckcmai.c
+ 118. http://www.columbia.edu/kermit/ckuins.html#x15
+ 119. ftp://kermit.columbia.edu/kermit/c-kermit/ckutio.c
+ 120. ftp://kermit.columbia.edu/kermit/c-kermit/ckufio.c
+ 121. ftp://kermit.columbia.edu/kermit/c-kermit/ckutio.c
+ 122. ftp://kermit.columbia.edu/kermit/c-kermit/ckufio.c
+ 123. ftp://kermit.columbia.edu/kermit/c-kermit/ckcnet.c
+ 124. ftp://kermit.columbia.edu/kermit/c-kermit/ckcnet.c
+ 125. ftp://kermit.columbia.edu/kermit/c-kermit/ckutio.c
+ 126. ftp://kermit.columbia.edu/kermit/c-kermit/ckcuni.c
+ 127. mailto:kermit-support@columbia.edu
+ 128. http://www.columbia.edu/kermit/ckuins.html#top
+ 129. http://www.columbia.edu/kermit/ckuins.html#contents
+ 130. http://www.columbia.edu/kermit/ckuins.html#x4
+ 131. http://www.columbia.edu/kermit/ckuins.html#x4.2
+ 132. http://www.columbia.edu/kermit/ckuins.html#x4.0
+ 133. ftp://kermit.columbia.edu/kermit/c-kermit/makefile
+ 134. ftp://kermit.columbia.edu/kermit/c-kermit/ckubwr.txt
+ 135. http://www.columbia.edu/kermit/ckubwr.html
+ 136. ftp://kermit.columbia.edu/kermit/c-kermit/ckwart.c
+ 137. ftp://kermit.columbia.edu/kermit/c-kermit/ckcpro.w
+ 138. ftp://kermit.columbia.edu/kermit/c-kermit/ckcpro.c
+ 139. http://www.columbia.edu/kermit/ckuins.html#top
+ 140. http://www.columbia.edu/kermit/ckuins.html#contents
+ 141. http://www.columbia.edu/kermit/ckuins.html#x4
+ 142. http://www.columbia.edu/kermit/ckuins.html#x4.3
+ 143. http://www.columbia.edu/kermit/ckuins.html#x4.1
+ 144. http://www.columbia.edu/kermit/ckuins.html#x5
+ 145. http://www.columbia.edu/kermit/ckuins.html#top
+ 146. http://www.columbia.edu/kermit/ckuins.html#contents
+ 147. http://www.columbia.edu/kermit/ckuins.html#x4
+ 148. http://www.columbia.edu/kermit/ckuins.html#x4.4
+ 149. http://www.columbia.edu/kermit/ckuins.html#x4.2
+ 150. http://www.columbia.edu/kermit/ckuins.html#top
+ 151. http://www.columbia.edu/kermit/ckuins.html#contents
152. http://www.columbia.edu/kermit/ckuins.html#x4
- 153. http://www.columbia.edu/kermit/ckuins.html#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
+ 153. http://www.columbia.edu/kermit/ckuins.html#x4.5
+ 154. http://www.columbia.edu/kermit/ckuins.html#x4.3
+ 155. ftp://kermit.columbia.edu/kermit/c-kermit/ckpker.mk
+ 156. http://www.columbia.edu/kermit/ckuins.html#top
+ 157. http://www.columbia.edu/kermit/ckuins.html#contents
+ 158. http://www.columbia.edu/kermit/ckuins.html#x4
+ 159. http://www.columbia.edu/kermit/ckuins.html#x4.4
+ 160. ftp://kermit.columbia.edu/kermit/c-kermit/makefile
+ 161. ftp://kermit.columbia.edu/kermit/c-kermit/makefile
+ 162. ftp://kermit.columbia.edu/kermit/c-kermit/ckcpro.w
+ 163. http://www.columbia.edu/kermit/ckuins.html#top
+ 164. http://www.columbia.edu/kermit/ckuins.html#contents
+ 165. http://www.columbia.edu/kermit/ckuins.html#x6
+ 166. http://www.columbia.edu/kermit/ckuins.html#x4
+ 167. http://www.columbia.edu/kermit/ckuins.html#x5.1
+ 168. http://www.columbia.edu/kermit/ckuins.html#x5.2
+ 169. http://www.columbia.edu/kermit/ckuins.html#x5.3
+ 170. http://www.columbia.edu/kermit/ckuins.html#x5.4
+ 171. http://www.columbia.edu/kermit/
+ 172. http://www.columbia.edu/kermit/ckuins.html#x5.4
+ 173. http://www.columbia.edu/kermit/ckuins.html#x5.3
+ 174. ftp://kermit.columbia.edu/kermit/c-kermit/COPYING.TXT
+ 175. ftp://kermit.columbia.edu/kermit/c-kermit/ckermit.ini
+ 176. http://www.columbia.edu/kermit/ckuins.html#x5.1
+ 177. ftp://kermit.columbia.edu/kermit/c-kermit/ckermod.ini
+ 178. ftp://kermit.columbia.edu/kermit/c-kermit/ckermit70.txt
+ 179. http://www.columbia.edu/kermit/ck60manual.html
+ 180. http://www.columbia.edu/kermit/ckermit70.html
+ 181. ftp://kermit.columbia.edu/kermit/c-kermit/ckermit80.txt
+ 182. http://www.columbia.edu/kermit/ck60manual.html
+ 183. http://www.columbia.edu/kermit/ckermit80.html
+ 184. ftp://kermit.columbia.edu/kermit/c-kermit/ckcbwr.txt
+ 185. http://www.columbia.edu/kermit/ckcbwr.html
+ 186. ftp://kermit.columbia.edu/kermit/c-kermit/ckubwr.txt
+ 187. http://www.columbia.edu/kermit/ckubwr.html
+ 188. ftp://kermit.columbia.edu/kermit/c-kermit/ckuins.txt
+ 189. http://www.columbia.edu/kermit/ckuins.html
+ 190. ftp://kermit.columbia.edu/kermit/c-kermit/ckccfg.txt
+ 191. http://www.columbia.edu/kermit/ckccfg.html
+ 192. ftp://kermit.columbia.edu/kermit/c-kermit/ckcplm.txt
+ 193. http://www.columbia.edu/kermit/ckcplm.html
+ 194. ftp://kermit.columbia.edu/kermit/c-kermit/ca_certs.pem
+ 195. http://www.columbia.edu/kermit/ckuins.html#x16"
+ 196. ftp://kermit.columbia.edu/kermit/c-kermit/makefile
+ 197. http://www.columbia.edu/kermit/ckuins.html#x?
+ 198. http://www.columbia.edu/kermit/ckuins.html#x11
+ 199. http://www.columbia.edu/kermit/ckuins.html#x5.2
+ 200. http://www.columbia.edu/kermit/ckermit.html#download
+ 201. http://www.columbia.edu/kermit/ck80binaries.html
+ 202. http://www.columbia.edu/kermit/ckermit.html#download
+ 203. http://www.columbia.edu/kermit/ckuins.html#top
+ 204. http://www.columbia.edu/kermit/ckuins.html#contents
+ 205. http://www.columbia.edu/kermit/ckuins.html#x7
+ 206. http://www.columbia.edu/kermit/ckuins.html#x5
+ 207. http://www.columbia.edu/kermit/ckuins.html#top
+ 208. http://www.columbia.edu/kermit/ckuins.html#contents
+ 209. http://www.columbia.edu/kermit/ckuins.html#x8
+ 210. http://www.columbia.edu/kermit/ckuins.html#x6
211. ftp://kermit.columbia.edu/kermit/c-kermit/ckutio.c
- 212. 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
+ 212. ftp://kermit.columbia.edu/kermit/c-kermit/ckutio.c
+ 213. http://www.columbia.edu/kermit/ckuins.html#x4.0
+ 214. ftp://kermit.columbia.edu/kermit/c-kermit/ckcdeb.h
+ 215. ftp://kermit.columbia.edu/kermit/c-kermit/ckufio.c
+ 216. ftp://kermit.columbia.edu/kermit/c-kermit/ckufio.c
+ 217. ftp://kermit.columbia.edu/kermit/c-kermit/ckutio.c
+ 218. http://www.columbia.edu/kermit/ckuins.html#x10
+ 219. http://www.columbia.edu/kermit/ckccfg.html#x2
+ 220. http://www.columbia.edu/kermit/ckccfg.html
+ 221. http://www.columbia.edu/kermit/ckuins.html#x4
222. http://www.columbia.edu/kermit/ckuins.html#x10
- 223. 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
+ 223. ftp://kermit.columbia.edu/kermit/c-kermit/ckutio.c
+ 224. ftp://kermit.columbia.edu/kermit/c-kermit/ckutio.c
+ 225. ftp://kermit.columbia.edu/kermit/c-kermit/ckutio.c
+ 226. http://www.columbia.edu/kermit/ckuins.html#x9.4
+ 227. mailto:kermit-support@columbia.edu
+ 228. http://www.columbia.edu/kermit/ckuins.html#top
+ 229. http://www.columbia.edu/kermit/ckuins.html#contents
+ 230. http://www.columbia.edu/kermit/ckuins.html#x9
+ 231. http://www.columbia.edu/kermit/ckuins.html#x7
+ 232. http://www.columbia.edu/kermit/ckccfg.html
+ 233. http://www.columbia.edu/kermit/ckccfg.html
+ 234. http://www.columbia.edu/kermit/ckuins.html#top
+ 235. http://www.columbia.edu/kermit/ckuins.html#contents
+ 236. http://www.columbia.edu/kermit/ckuins.html#x10
+ 237. http://www.columbia.edu/kermit/ckuins.html#x8
+ 238. http://www.columbia.edu/kermit/ckuins.html#x9.1
+ 239. http://www.columbia.edu/kermit/ckuins.html#x9.1.1
+ 240. http://www.columbia.edu/kermit/ckuins.html#x9.1.2
+ 241. http://www.columbia.edu/kermit/ckuins.html#x9.1.3
+ 242. http://www.columbia.edu/kermit/ckuins.html#x9.2
+ 243. http://www.columbia.edu/kermit/ckuins.html#x9.3
+ 244. http://www.columbia.edu/kermit/ckuins.html#x9.4
+ 245. http://www.columbia.edu/kermit/ckuins.html#x9.5
+ 246. http://www.columbia.edu/kermit/ckuins.html#x9.6
+ 247. http://www.columbia.edu/kermit/ckuins.html#x9.7
+ 248. http://www.columbia.edu/kermit/ckuins.html#x9.8
+ 249. http://www.columbia.edu/kermit/ckuins.html#x9.9
+ 250. ftp://kermit.columbia.edu/kermit/c-kermit/ckutio.c
+ 251. http://www.columbia.edu/kermit/ckuins.html#top
252. http://www.columbia.edu/kermit/ckuins.html#x9
- 253. http://www.columbia.edu/kermit/ckuins.html#x9.1
+ 253. http://www.columbia.edu/kermit/ckuins.html#contents
254. http://www.columbia.edu/kermit/ckuins.html#x9.2
- 255. http://www.columbia.edu/kermit/ckuins.html#x9.1.2
- 256. http://www.opengroup.org/onlinepubs/007904975/
- 257. http://www.columbia.edu/kermit/ckuins.html#x9.1.1
+ 255. http://www.columbia.edu/kermit/ckuins.html#x9.1.1
+ 256. http://www.columbia.edu/kermit/ckuins.html#x9.1.2
+ 257. http://www.columbia.edu/kermit/ckuins.html#x9.1.3
258. http://www.columbia.edu/kermit/ckuins.html#top
259. http://www.columbia.edu/kermit/ckuins.html#contents
260. http://www.columbia.edu/kermit/ckuins.html#x9
261. http://www.columbia.edu/kermit/ckuins.html#x9.1
- 262. http://www.columbia.edu/kermit/ckuins.html#x9.3
- 263. http://www.columbia.edu/kermit/ckuins.html#x9.1
+ 262. http://www.columbia.edu/kermit/ckuins.html#x9.1.3
+ 263. http://www.columbia.edu/kermit/ckuins.html#x9.1.1
264. http://www.columbia.edu/kermit/ckuins.html#top
265. http://www.columbia.edu/kermit/ckuins.html#contents
266. http://www.columbia.edu/kermit/ckuins.html#x9
- 267. http://www.columbia.edu/kermit/ckuins.html#x9.4
+ 267. http://www.columbia.edu/kermit/ckuins.html#x9.1
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
+ 269. http://www.columbia.edu/kermit/ckuins.html#x9.1.2
+ 270. http://www.opengroup.org/onlinepubs/007904975/
+ 271. http://www.columbia.edu/kermit/ckuins.html#x9.1.1
272. http://www.columbia.edu/kermit/ckuins.html#top
273. http://www.columbia.edu/kermit/ckuins.html#contents
274. http://www.columbia.edu/kermit/ckuins.html#x9
- 275. http://www.columbia.edu/kermit/ckuins.html#x9.5
+ 275. http://www.columbia.edu/kermit/ckuins.html#x9.1
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
+ 277. http://www.columbia.edu/kermit/ckuins.html#x9.1
+ 278. http://www.columbia.edu/kermit/ckuins.html#top
+ 279. http://www.columbia.edu/kermit/ckuins.html#contents
+ 280. http://www.columbia.edu/kermit/ckuins.html#x9
+ 281. http://www.columbia.edu/kermit/ckuins.html#x9.4
+ 282. http://www.columbia.edu/kermit/ckuins.html#x9.2
+ 283. ftp://kermit.columbia.edu/kermit/c-kermit/ckufio.c
+ 284. ftp://kermit.columbia.edu/kermit/c-kermit/ckutio.c
+ 285. ftp://kermit.columbia.edu/kermit/c-kermit/ckufio.c
+ 286. http://www.columbia.edu/kermit/ckuins.html#top
+ 287. http://www.columbia.edu/kermit/ckuins.html#contents
+ 288. http://www.columbia.edu/kermit/ckuins.html#x9
+ 289. http://www.columbia.edu/kermit/ckuins.html#x9.5
+ 290. http://www.columbia.edu/kermit/ckuins.html#x9.3
+ 291. http://www.columbia.edu/kermit/cable.html
+ 292. ftp://kermit.columbia.edu/kermit/c-kermit/ckutio.c
+ 293. ftp://kermit.columbia.edu/kermit/c-kermit/ckcdeb.h
+ 294. http://www.columbia.edu/kermit/ckuins.html#top
+ 295. http://www.columbia.edu/kermit/ckuins.html#contents
+ 296. http://www.columbia.edu/kermit/ckuins.html#x9
+ 297. http://www.columbia.edu/kermit/ckuins.html#x9.6
+ 298. http://www.columbia.edu/kermit/ckuins.html#x9.4
+ 299. ftp://kermit.columbia.edu/kermit/c-kermit/ckcdeb.h
+ 300. ftp://kermit.columbia.edu/kermit/c-kermit/ckuus3.c
+ 301. ftp://kermit.columbia.edu/kermit/c-kermit/ckutio.c
+ 302. http://www.columbia.edu/kermit/ckuins.html#top
+ 303. http://www.columbia.edu/kermit/ckuins.html#contents
+ 304. http://www.columbia.edu/kermit/ckuins.html#x9
+ 305. http://www.columbia.edu/kermit/ckuins.html#x9.7
+ 306. http://www.columbia.edu/kermit/ckuins.html#x9.5
+ 307. http://www.columbia.edu/kermit/ckuins.html#top
+ 308. http://www.columbia.edu/kermit/ckuins.html#contents
+ 309. http://www.columbia.edu/kermit/ckuins.html#x9
310. http://www.columbia.edu/kermit/ckuins.html#x9.8
- 311. http://www.columbia.edu/kermit/ckuins.html#top
- 312. http://www.columbia.edu/kermit/ckuins.html#contents
- 313. http://www.columbia.edu/kermit/ckuins.html#x11
+ 311. http://www.columbia.edu/kermit/ckuins.html#x9.6
+ 312. http://www.columbia.edu/kermit/ckuins.html#top
+ 313. http://www.columbia.edu/kermit/ckuins.html#contents
314. http://www.columbia.edu/kermit/ckuins.html#x9
- 315. 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
+ 315. http://www.columbia.edu/kermit/ckuins.html#x9.9
+ 316. http://www.columbia.edu/kermit/ckuins.html#x9.7
+ 317. ftp://kermit.columbia.edu/kermit/c-kermit/ckutio.c
+ 318. ftp://kermit.columbia.edu/kermit/c-kermit/ckutio.c
+ 319. ftp://kermit.columbia.edu/kermit/c-kermit/ckcdeb.h
+ 320. ftp://kermit.columbia.edu/kermit/c-kermit/ckufio.c
+ 321. http://www.columbia.edu/kermit/ckuins.html#top
+ 322. http://www.columbia.edu/kermit/ckuins.html#contents
+ 323. http://www.columbia.edu/kermit/ckuins.html#x9
+ 324. http://www.columbia.edu/kermit/ckuins.html#x10
+ 325. http://www.columbia.edu/kermit/ckuins.html#x9.8
+ 326. http://www.columbia.edu/kermit/ckuins.html#top
+ 327. http://www.columbia.edu/kermit/ckuins.html#contents
+ 328. http://www.columbia.edu/kermit/ckuins.html#x11
+ 329. http://www.columbia.edu/kermit/ckuins.html#x9
+ 330. ftp://kermit.columbia.edu/kermit/c-kermit/ckutio.c
+ 331. http://www.columbia.edu/kermit/ckuins.html#x11
+ 332. http://www.columbia.edu/kermit/ckuins.html#top
+ 333. http://www.columbia.edu/kermit/ckuins.html#contents
+ 334. http://www.columbia.edu/kermit/ckuins.html#x12
+ 335. http://www.columbia.edu/kermit/ckuins.html#x10
+ 336. ftp://kermit.columbia.edu/kermit/c-kermit/ckutio.c
+ 337. ftp://kermit.columbia.edu/kermit/c-kermit/ckufio.c
+ 338. http://www.columbia.edu/kermit/ckuins.html#top
+ 339. http://www.columbia.edu/kermit/ckuins.html#contents
+ 340. http://www.columbia.edu/kermit/ckuins.html#x13
+ 341. http://www.columbia.edu/kermit/ckuins.html#x11
+ 342. http://www.columbia.edu/kermit/ckuins.html#top
+ 343. http://www.columbia.edu/kermit/ckuins.html#contents
+ 344. http://www.columbia.edu/kermit/ckuins.html#x14
+ 345. http://www.columbia.edu/kermit/ckuins.html#x12
+ 346. ftp://kermit.columbia.edu/kermit/c-kermit/ckubwr.txt
+ 347. ftp://kermit.columbia.edu/kermit/c-kermit/ckutio.c
+ 348. http://www.columbia.edu/kermit/ckuins.html#top
+ 349. http://www.columbia.edu/kermit/ckuins.html#contents
+ 350. http://www.columbia.edu/kermit/ckuins.html#x15
+ 351. http://www.columbia.edu/kermit/ckuins.html#x13
352. http://www.columbia.edu/kermit/ckuins.html#top
353. http://www.columbia.edu/kermit/ckuins.html#contents
354. http://www.columbia.edu/kermit/ckuins.html#x16
- 355. http://www.columbia.edu/kermit/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
+ 355. http://www.columbia.edu/kermit/ckuins.html#x14
+ 356. http://www.columbia.edu/kermit/uiksd.html#x4.2
+ 357. http://www.columbia.edu/kermit/uiksd.html
+ 358. http://www.columbia.edu/kermit/ckermit2.html
+ 359. http://www.columbia.edu/kermit/ckuins.html#top
+ 360. http://www.columbia.edu/kermit/ckuins.html#contents
+ 361. http://www.columbia.edu/kermit/ckuins.html#x17
+ 362. http://www.columbia.edu/kermit/ckuins.html#x15
+ 363. http://www.columbia.edu/kermit/security.html
+ 364. http://www.columbia.edu/kermit/security80.html
+ 365. http://www.columbia.edu/kermit/ckuins.html#top
+ 366. http://www.columbia.edu/kermit/ckuins.html#contents
+ 367. http://www.columbia.edu/kermit/ckuins.html#x16
+ 368. http://www.columbia.edu/kermit/skermit.html
+ 369. http://www.columbia.edu/kermit/ckuins.html#top
+ 370. http://www.columbia.edu/kermit/ckuins.html#contents
+ 371. http://www.columbia.edu/kermit/ckermit.html
+ 372. http://www.columbia.edu/kermit/ck90updates.html
+ 373. http://www.columbia.edu/kermit/index.html
projects / ckermit.git / blobdiff