ckuins.doc

linux终端仿真程序

function does something else or uses some other units of time (like the NCR
Tower 32, which uses clock-ticks), do not include -DNAP.

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

  -DNAPHACK

NONDESTRUCTIVE INPUT BUFFER PEEKING

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

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

  -DSELECT

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

  -DNOSELECT

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

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

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

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

  -DCK_POLL

OTHER SYSTEM-DEPENDENT FEATURES

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

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

  -DNOIEXTEN

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

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

  -DNOSETBUF

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

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

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

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

  -DNOFDZERO

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

  -DCLSOPN

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

  -DNOCOTFMC

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

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

  -DRENAME

C-Kermit predefines the RENAME for several UNIX versions in 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:

  1. Linker complains that _rename is an unresolved symbol.

  2. Linking works, but Kermit's RENAME command doesn't work (which happens
     because older versions of rename() might have their arguments reversed).

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

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

  -DISDIRBUG

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

  -DCOMMENT

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

TERMINAL INTERRUPTION

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

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

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

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

  -DSVR3JC

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

  -DCK_POSIX_SIG

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

DIALING OUT AND COORDINATING WITH UUCP

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 & Network Manager's Guide, or
the Terminals and Modems section of the HP manual, "Configuring HP-UX for
Peripherals".

Unlike other operating systems, UNIX allows multiple processes to access the
same tty device at the same time, even though there is no earthly reason why
two processes would want to do this.  When they do, process A will read some
of the incoming characters, and process B will read the others.  In all
likelihood, neither process will see them all.  As you can imagine, this can
cause enormous difficulties for any communication program.

Rather than change UNIX to make exclusive access to tty devices be the
default, UNIX developers hit upon the idea of a "lock file".  Any process that
wants to open a tty device should first check and see if a file of a certain
name exists, and if so, not to open the device.  If the file does not exist,
the process creates the file and then opens the device.  When the process
closes the device, it destroys the lockfile.  This procedure was originated
for use with UNIX's UUCP, CU, and TIP programs, and so these lockfiles are
commonly called "UUCP lockfiles" (UUCP = UNIX-to-UNIX Copy Program).

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

  - If a process does not observe the prevailing lockfile convention, then it
    can interfere with other "polite" processes.

  - 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, and specify their contents differently.

  - On a given system, the lockfile conventions may change from one UNIX 
    release to the next (for example, SunOS 4.0 to 4.1).

  - The same tty device might have more than one name, and most lockfile
    conventions don't allow for this.

In order to fit in with UUCP and other UNIX-based communication software,
C-Kermit must have the same idea as your system's uucp, cu, and tip programs
about what the UUCP lock directory is called, what the lockfile itself is
called, and what its contents should be.  In most cases, Kermit tries to
figure this out automatically (see ckutio.c).  The following CFLAGS options
can be used to override C-Kermit's normal assumptions:

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

  -DACUCNTRL: Tells Kermit to use the BSD 4.3 acucntrl() program