ckuins.doc

linux终端仿真程序

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

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

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

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

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

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

  make bsd KFLAGS=-DSIG_V

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

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

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

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

  cc -o wart ckwart.c

or:

  touch ckcpro.c

and then give the "make" command again.

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

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

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

UNIX FILE SYSTEM PECULIARITIES

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

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>.

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

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

  -DDIRENT   - #include <dirent.h>
  -DSDIRENT  - #include <sys/dirent.h>
  -DNDIR     - #include <ndir.h>
  -DXNDIR    - #include <sys/ndir.h>
  -DRTU      - #include "/usr/lib/ndir.h", only if NDIR and XNDIR not defined.
  -DSYSUTIMH - #include <sys/utime.h> for setting file creation dates.
  
(Note, RTU should only be used for Masscomp RTU systems, because it also
selects certain other RTU-specific features.)

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

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

Another problem child is <sys/file.h>.  Most UNIX C-Kermit versions need to
#include this file from within ckutio.c and ckufio.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 entry:

  -DNOFILEH

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

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

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

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

  -DMATCHDOT

If you get compile-time complaints about data type mismatches for process-ID
related functions like getpid(), add -DPID_T=pid_t.

If you get compile-time complaints about data type mismatches for user ID
related functions like getuid(), add -DUID_T=uid_t.

If you get compile-time complaints about data type mismatches for user-ID
related functions like getgid(), add -DGID_T=gid_t.

If you get compile-time complaints about data type mismatches for getpwuid(),
add -DPWID_T=uid_t (or whatever it should be).

HARDWARE FLOW CONTROL

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

1. POSIX does not support hardware flow control.

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

     -DTERMIOX

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

     -DSTERMIOX

   Note that the presence of this file does not guarantee that RTS/CTS will
   actually work -- that depends on the device-driver implementation
   (reportedly, many UNIX versions treat hardware-flow-control related ioctl's
   as no-ops).

3. 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).

4. 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)

5. RTS/CTS is available in Linux, but you have to place a line like:

     stty crtscts < /dev/modem

   in your /etc/rc.local file (where /dev/modem is the device name of
   any serial device that you want to have RTS/CTS flow control enabled).

See the routine tthflow() in 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:

 1. See if it agrees with one of the methods already used in tthflow().
    If not, add new code, appropriately #ifdef'd.

 2. Add -DCK_RTSCTS to the compiler CFLAGS in your makefile entry or define
    this symbol within the appropriate #ifdef's in ckcdeb.h.

To illustrate the difficulties with RTS/CTS, here is a tale from Jamie Watson
<[e-mail]>, who added the RTS/CTS code for the RS/6000, about his
attempts to do the same for DEC ULTRIX:

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

TERMINAL SPEEDS

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

MILLISECOND SLEEPS

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

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

NOTE: The nap() function is assumed to be a function that puts the process
to sleep for the given number of milliseconds.  If your system's nap()