Columbia Kermit/kermit.zip/old/ckermit4f/ckuker.bwr

Text File | 2020-01-01 | 36KB | 912 lines

C-Kermit Version 4F(091):
Status, Bugs, and Problems
As of: Sat Aug  5 16:47:20 1989

See the file ckuker.upd for a history of the changes that were made and
bugs that were fixed in each release.


BUILDING C-KERMIT

See the file ckuker.mak for instructions on building C-Kermit for different
UNIX systems.  To use the ckuker.mak file, rename it to "makefile" or
"Makefile", and give the UNIX command "make xxx", where "xxx" designates which
kind of system you want to build C-Kermit for, e.g. "make bsd", "make xenix".

ON PC's...  If you have received C-Kermit on MS-DOS format diskettes (such as
those distributed by Columbia), you should make sure that your DOS-to-UNIX
conversion utility both: (1) changes line terminators in all files from
carriage-return linefeed (CRLF) to just linefeed (LF) and remove any Ctrl-Z's,
and (2) that all filenames are converted from uppercase to lowercase.  You
can use the following shell script to do this:
---(cut here)---
#!/bin/sh
#
# Shell script to convert C-Kermit DOS-format files into Unix format.
# Lowercases the filenames, strips out carriage returns and Ctrl-Z's.
#
x=$1    # the name of the source directory
y=$2    # the name of the target directory
if [ $# -lt 2 ]; then
  echo "usage: $0 source-directory target-directory"
  exit 1
fi
if cd $1 ; then
  echo "Converting $1 files into $2"
else
  echo "$0: cannot cd to $1"
  exit 1
fi
for i in *; do
  j=`echo $i | tr 'A-Z' 'a-z'`
  echo $x/$i =\> $y/$j
  tr -d '\015\032' < $i > $y/$j
done
---(cut here)---
Cut out this shell script, save it as "convert.sh" (or any other name you
prefer), then "chmod +x convert.sh".  Then, create a new, empty directory
to put the converted files in, and then "convert.sh /xxx /yyy" where /xxx
is the name of the directory where the PC-format files are, and /yyy is the
name of the new, empty directory.  The converted files will appear in the
new directory.

------------------------------

Date: Wed, 26 Jul 89 21:32:01 MDT
From: [e-mail] (Brad Davis)
To: [e-mail]
Subject: Minor fix to C-Kermit 4F(085).

Doing a make bsd43, I had to comment out the extra #include's in ckutio.c
marked below.  Both files seem to be included somewhere else.

/* Whether to #include <sys/file.h>... */
#ifndef PROVX1
#ifndef aegis
#ifndef XENIX
#ifndef unos
#include <sys/file.h>                   /* File information */
#endif /* unos */
#endif /* xenix */
#endif /* aegis */
#endif /* provx1 */

#ifdef aegis
/* #include <sys/file.h> */
#include <fcntl.h>
#endif /* aegis */

#ifdef BSD4
/*#include <sys/file.h>*/        ------ Remove ------
/*#include <fcntl.h>*/            ------ Remove ------
#endif /* BSD4 */

Brad Davis
University of Utah

------------------------------

C-Kermit can also be built for VAX/VMS -- see the files ckv*.com and
ckvker.bwr for further information.  Similarly for the Apple Macintosh
(ckm*.*), Commodore Amiga (cki*.*), Data General AOS/VS (ckd*.*), etc.  This
file applies only to the UNIX versions.

Following are hints, beyond what might be found in ckuker.mak, about building
C-Kermit for various UNIX systems.

HP Integral PC -- "make sys3", but either remove code that sets up lock files,
or have the lock files put in a directory that is guaranteed to be there,
like /tmp.  Some problems reported when running under csh.

Most System V or System III based systems can build a working Kermit with
"make sys3" or "make sys3nid" or "make att3bx" or (for Sys 5 R3) "make
sys5r3".

Xenix variations of System III/V have their own makefile entries, "make
xenix", "make sco286", etc.

AT&T System V R3 has redefined the type of the signal() function.  Use
"make sys5r3".  If that doesn't work (as reportedly it does not on certain
recent Xenix systems), "make sys3" or "make xenix".

AT&T 7300 has its own make option, "make sys3upc" as of 4E(068), to allow
operation with its internal modem and system support thereof.

PDP-11's running a System III or V based Unix and which have no I & D space
should use "make sys3nid".

DEC Pro-350 or -380 with Pro/Venix V2 (not V1) -- uses the regular "make sys3"
or "make sys3nid", but the file ckufio.c might have to be edited first to
reduce the value of MAXWLD and/or SSPACE.  See below under HINTS for details.

Valid Scaldstar CAD system -- There's a "make valid" in the makefile, but
reportedly one thing is still lacking: ckutio.c needs to #include<sys/file.h>.

-- HINTS --

- If the program dies with a message like "malloc fails in splitpath()"
  whenever it tries to parse a filename (as in the "send" command), then
  the amount of space allocated for filename expansion in the module
  ckufio.c must be reduced.  This can be done by changing the #defines
  for MAXWLD (the maximum number of filenames) and SSPACE (the size of
  static string space) to make the numbers smaller.

- When modifying or writing Kermit code, do not pass to a function
  (e.g., "signal") the address of a static function.  Doing so may
  break VENIX code mapping.  If you must pass the address of the
  function, make it global and pick a "non-generic" name for it that
  will hopefully be unique and yet informative.


-- BUG LIST --

*** 4F(089) is a field test, not formally released ***

Specific problems with 4F(089):

The block check option is negotiated and used correctly, but is incorrectly
reported by the SHOW command after a file transfer.

-----------

First, a disclaimer must be made.  C-Kermit attempts to support all post-V6
Unix variations on all machines.  This is a tall order, and requires careful
attention to certain details.  As changes are made (and C-Kermit is still in
stage of fairly rapid development), there is always the chance that a change
-- made to introduce a new feature or fix a bug -- will not work as intended
on some systems, even though it was tested successfully on others.  The main
area to watch out for is not system differences (which are handled fairly well
in the system-dependent ck?[ft]io modules), but in compiler differences,
especially signed/unsigned int/char confusion.  Characters should be stored in
variables of type char, not int, and char/int conversion should be avoided
because of problems introduced by sign extension.  And i/o should not be used
to read characters into int variables, because the way in which the system
stores the character in an int varies from system to system (e.g. 68000s put
them on the left, the VAX on the right).

If you have received a C-Kermit release that does not work correctly (except
for the bugs & restrictions noted below), it is not because the release was
not thoroughly tested -- it was -- but because it was not tested on your system
since the last time changes were made, because of a lack of such a system to
test it on.  If this happens to you, please try to track down the problem and
report as specifically as possible back to Columbia.


General problems:

- The program is too big, with too many features; source is too large to fit on
  some disks.  Needs to be reorganized so that a minimal Kermit can be built
  for any system, and then frills can be added on if desired -- interactive
  command parser, help strings, dial command, script command, etc.

- There's not a full enough set of features available from command line
  invocation.  Commands like "bye" are missing.  This is mainly to keep the
  "kermit -h" help message small enough to fit on one screen.

- Conditionalizations are not done clearly.  In some cases it might be
  better to have compile-time flags for features, rather than systems, or
  generic system names, rather than specific vendor/machine names, to
  avoid excessive nesting or repitition of compile-time variables.
  Constructions like "#ifdef FOO | BAR" are avoided because many compilers
  don't understand them; the alternative is to repeat code under different
  conditionals (to accomplish an OR) or to include it within nested
  conditionals (AND), sometimes applying De Morgan's law to achieve the
  desired result...

- Program's return code might be wrong in some cases (in 4.0, it was always
  zero; in 4C some attempt is made to return correct codes for failure and
  success).  Actually, no attempt has been made to correlate return codes
  with success or failure of file transfer -- a bad return code only reflects
  a fatal error.

- On some systems (e.g. TRS-80 Model 16 with Xenix V7, or HP-9000 HP-UX)
  C-Kermit reportedly runs VERY SLOWLY.  The program could certainly do with
  some tuning -- but not at the expense of modularity and transportability! --
  but in the meantime, it can probably be sped up a lot by removing the
  -DDEBUG from the makefile, eliminating hundreds of function calls, many of
  them in critical code (one user reported a 1250% improvement doing this on
  the TRS-80 Model 16, with an earlier Kermit version.).

- In reality, TANDEM flow control (XON/XOFF) is not really done on most
  systems, because Kermit opens the communication line in rawmode, which
  has the side effect of disabling flow control.  Rawmode is used in order
  to allow 8-bit data.  Using cooked mode & CRMOD would be possible for
  text files, but 8th-bit prefixing would be required for 8-bit binary
  files.  But at least this would allow in-band flow control to take place.
  Allegedly, 4.3BSD and Sys 5 R3 allow XON/XOFF and rawmode to coexist,
  but this hasn't been verified.  It doesn't seem to happen on Ultrix 2.0.

- The timeout interval is not automatically adjusted according to the
  packet length.

- The program could be a little bit less cavalier in its treatment of files.
  For instance, when receiving a file (with "warning" turned off) it will
  overwrite any existing file of the same name.  That's ok, but what if the
  user types ^F or ^B to interrupt the transfer?  This does not save the
  existing file -- it's already been destroyed by the open() of the new copy,
  which in turn is discarded as a result of the interruption.  Maybe Kermit
  should always make a temporary, unique name for incoming files, and then
  rename them to their real names only after the transfer is complete.  But
  that's no good on systems (like the Macintosh) that don't have disk space
  to burn.

- Local versus remote mode is not, and probably can not, be determined
  automatically upon startup.  For instance, if you build Kermit with
  "make sys3" on a 3B20 and a 3B2, the program has no way of knowing whether
  it's running on a timesharing system (the 3B20, where it should be remote
  by default) or a workstation (the 3B2, where it should be local by default).
  If you find that Kermit comes up on your system in the wrong mode, you can
  put the appropriate "set line" command in your .kermrc file -- "set line
  /dev/tty" SHOULD always put you in remote mode.  (Actually, problems have
  been reported for this on some systems that support incoming X.25 connections
  on pseudoterminals.)

- If the program crashes or is halted (killed) from outside while it has the
  terminal in a not-normal mode during command parsing or file transfer, the
  terminal mode is not restored, and lock files are not cleaned up.  There can
  be no fix for this within C-Kermit itself.  Subsequent Kermit runs may still
  fail because the device is already opened by "another process" (you have
  to log out & log in again to clear this one up).

- The shell's interrupt, delete, and kill characters may interfere or
  conflict with those used by the Kermit command parser.  In any case, there
  is no way to change Kermit's editing characters to conform to user's taste.

- "!" command requires a space after, contrary to the Unix user's normal
  expectation.

- Many people have asked for a system-wide startup file similar to
  the user's .kermrc file, perhaps with a conditional way to escape from
  it if the user has her own .kermrc file.  This notion might be extended
  to include the entire hierarchy system -- home -- current directory.

- Some users report that it would be more desirable to have an error during
  execution of a take file return directly to command level, rather than
  pop to the invoking take file, in case the error in question is of such
  severity that it would cause all subsequent commands in the stack of TAKE
  files to fail.  Best to have a SET command to control this behavior.
  (This desired behavior does occur -- or at least should occur -- when the
  program is in the background.)

- Some users report that the program should make no internal distinction
  between running in foreground or background, so that program exit codes
  are consistent, making it easier to debug shell scripts that invoke Kermit.

- Speaking of background, not all systems seem to define it the same way.
  If your prompt disappears, you probably have one of those systems.  See
  function conint() in ckutio.c, and try to figure out what's amiss.

- Since Kermit opens and closes the communication line with each command line
  invocation, it is not convenient to use it in scripts in which it is
  repeatedly invoked (e.g. a print spooler).

- Opening & closing a comm line selected with 'set line' involves the use
  of UUCP "lock files", whose use is inconsistent from one Unix variation to
  another, and from site to site and system to system.  The lack of a
  consistent, reliable way to guarantee exclusive access to a communication
  line is one of Unix's biggest shortcomings.

- There is very little provision in the program (as yet) for running setuid.
  Nor for dealing with bidirectional terminal lines.  Nor with system-provided
  dialer programs.  Every system does these things differently.

- Variable names are sometimes confusing, especially the send/receive parameter
  pairs (spsiz/rpsize, mystch/stchr, npad/mypadn, rtimo/timint, etc).  This
  is mostly history... they tend to agree with the names used in other Kermit
  programs.  Still, they should probably be changed.  Ditto for some of the
  procedure names.

- Some C compilers do not support variable names longer than 6, nor function
  names longer than 5, and some are not case sensitive (one DEC-20 C compiler
  has all these restrictions, and the V6 Unix C compiler has some of them).
  To ensure the widest possible portability, all identifiers should comply
  with these restrictions -- currently many do not.

- When the C-Kermit server is given a host command (or even some generic
  commands like 'space'), it might have to think for a long time before
  returning output.  In this case, it should set a timer while waiting for
  input from the fork and whenever the timer goes off, it should send a null
  data packet to prevent the other Kermit from timing out.

- When connecting back to C-Kermit after a transaction, or after finishing
  the server, it may be necessary to type a ^Q to clear up an XOFF deadlock.
  There's not much the Kermit program can do about this...

- When interrupting a send with ^F or ^B, an appropriate message does not
  seem to make it into the transaction log.

- There should be a nonverbose transaction log, in the Unix tradition,
  which can be read by another program.  For instance, if Kermit is
  used to 'send *', but only certain of the files make across successfully,
  another program could read the list of those files and do something to
  them (like (re)move them), or making a list of unsent files for Kermit to
  send next time.

- The program should be interruptable at any point -- in interactive command
  mode, during file transfer (but not during CONNECT), by Ctrl-C, which should
  return you to the command prompt, rather than always exiting.

- Don't try to run Kermit in remote mode while running the "screen" virtual
  terminal manager.   Screen (by default) uses Ctrl-A as its hot key, and this
  conflicts with the Kermit protocol  Either change screen's hot key, or
  change Kermit's start-of-packet character to some other control character.

ckucmd.c:

- Interactive Kermit commands that come in from a pipe (as in
  "cat foo | kermit") are echoed.  Some people think they should not be.
  The fix can be made (at some expense) in getwd() by adding a line to
  the first if () {} block, "if (!isatty(0)) echof = 1;".
  (Not sure if this is still true...)

ckufio.c:

- ckufio currently goes to a lot of trouble to traverse the directory in
  order to expand "*" and "?" in wildcards.  Maybe it should just fork the
  user's customary shell and have it do the expansion.  This would allow
  fancier filespecs to be given, like "~/ck*.[cwh]".  But it would slow down
  features like filename completion and menus in the interactive command
  parser.  (Find out how Unix FTP does it...)

  Another solution to the interactive command parsing problems would be to use
  the CCMD package (which grew out of Kermit's interactive command parser),
  but CCMD has not been adapted to VMS, Data General, and other environments
  that Kermit runs in.

ckutio.c:

- There's no good way to select baud rates higher than 9600.  Most Unix systems
  don't supply symbols for them (unless you use EXTA, EXTB), and even when they
  do, the program has no way of knowing whether a specific port serial
  controller supports those rates.  (This was partially addressed in 4E(071).)

- On some systems, there is an undesired interaction between the various
  open() modes, fnctl(), and ioctl() invocations when modem-control lines
  are involved.  Some of this due to bugs in some Unix implementations or to
  inconsistencies between them (e.g. as to the behavior of TIOCEXCL, etc).
  In particular, the whole business about opening modem-controlled lines
  with O_NDELAY before dialing and then switching modes after causes no end of
  confusion and trouble (addressed to some degree in 4E(072-074).

- The Sys III/V code in tthang() is confusing, and possibly incorrect --
  the closing and reopening of the ttyfd.  Often produces an annoying message
  "Problem hanging up phone".

ckudia.c:

- Some systems do not allow users to manipulate dialers directly.
- Should support a "phone book" (this would actually go in ckuus*.c).
- Pro/Venix V2 (and some other Sys V-based systems) are having DTR-dropping
  problems when dialing.  With Pro/Venix V2, a workaround is to get the system
  to ignore the modem control signals and treat the line as a direct line by
  issuing a "setline -d xxx" command, where "xxx" is the device node (e.g.
  com1), rather than "setline -m xxx".
- Should do "demon dialing" (keep trying till there's a connection).

ckuus*.c:

- When an alternate filename is given for an incoming file name, and the
  alternate name is uppercase, the name is lowercased.  Alternate names
  should be taken literally.

- Baud rate selection currently requires user to type a number, which is
  then verified against a system-dependent table.  Better to have a baud rate
  keyword (cmkey) table defined in the system-dependent module, so user
  can abbreviate (e.g. '9' for '9600').  Also, it's a pain having parallel
  tables in ckuus3.c, ckutio.c, etc.  Should consolidate this.

- No way to put trailing comments on commands.

- ckuus2.c reportedly makes the C optimizer run out of space under PC/IX and
  some other systems.  C compilers just don't like strings...

Protocol (ckcpro.w, ckcfn*.c):

- No way to interrupt a protocol transaction until after it starts
  successfully.  For instance, no way to interrupt the timeouts and
  retransmissions of the initial packet when the other side is not
  responding, except for killing the whole program.  Cure: check for
  keyboard "interrupts" during the send-init process, set c[xz]seen.
  But doing this will make the state table a lot more complicated...
  Maybe change ^C trap to get back to command mode rather than exit
  the program.

ckucon.c:

- Doesn't do any particular kind of terminal emulation.  It wasn't meant to.
  Filters can be used for this.  Or a replacement module can be written
  (as has been done for the Macintosh, or OS/2).

- When sending BREAK, should clear output buffer first (this is done in BSD,
  should be added for other systems to ttsndb() in ckutio.c).

- Performance is poor on systems that can't check the input buffer or
  do nonblocking read() calls.  See the horrendous code that was added for V7
  to get around this (peeking into tty buffers in kernel memory).

- As structured, connect mode can't include commands to toggle logging on
  and off or to change settings, because the fork that reads keyboard input
  doesn't share variables with the fork that does port i/o.

- Reportedly, a control-S typed at the keyboard doesn't always seem to "take"
  when doing terminal emulation under Pro/Venix V2 (DEC micros, terminals,
  devices, systems are notorious for their insistence on doing XON/XOFF and
  attendant problems.  Remember the VT180?)

- Should have a shell escape ("push").

------------------------------

KNOWN BUGS

Ctrl-C out of dialing sometimes results in "longjump botch" and core dump, at
least on VAX/Ultrix with "set modem rolm".  (Cure: interrupt handler should
not use longjmp's, but instead should set a flag and return, the way it's done
in the transmit() function as of 4F(089).

------------------------------

COLLECTED COMMENTS AND HINTS FROM USERS AND DEVELOPERS:

Date: Sun, 24 Nov 85 04:16:02 CST
From: Stan Barber <neuro1![e-mail]>
Subject: more notes on C-kermit 4C(057)
Organization: Neurophysiology, Baylor College of Medicine, Houston, Tx

One more suggestion:

I would provide some mechanism to allow SYSIII compatible sites to
configure what signal that might like to use to allow the child and
parent to notify each other of problems. At my site, SIGUSR1 can not
be used by kermit, so I modify ckucon.c by replacing SIGUSR1 with
SIGUSR2. That fixes everything just fine.

At least a warning should be noted somewhere (in the .bwr file, I guess)
so that people will know to change it.

Alternatively, I would suggest a unique name (SIGKERMIT) that the
installer can define in the makefile (e.g. -DSIGKERMIT=SIGUSR2) to
keep people from mucking in the source file.

------------------------------

Date:  9 Apr 1986 1105-EST (Wednesday)
From: Vic Abell <[e-mail]>
Subject: Kermit and 4.xBSD rlogin

There is an undocumented option on the 4.xBSD rlogin call that must be used
when C Kermit is at the end of a TCP/IP rlogin connection.  The option is "-8"
and should be used in the following fashion:

    % rlogin hostname -8
    % kermit

Vic Abell, Purdue University Computing Center
[e-mail], ...!pur-ee!pucc-j!abe

------------------------------

Date: Fri 5 Sep 86 13:59:44-EDT
From: Fred Wang <[e-mail]>
Subject: problem compiling kermit on the 3b2/310

If Mr. Ray's 3b2/310 is running the new C compiler (CFP+) he will run into
problems when he issues the 'make att3bx' command.  CFP+ uses the 'fpcc'
rather than the conventional 'cc' to compile C programs.

My suggestion to Mr. Ray's problem (if indeed he has CFP+) is to substitute
fpcc for cc in the variables CC and CC2 in the makefile text. This worked fine
for my 3b2/310 running Unix System V 2.0.4 with CFP+ C compiler.

------------------------------

Date: Wed 19 Jul 89 22:03:23-MDT
From: "Nelson H.F. Beebe" <[e-mail]>
Subject: C-Kermit Makefile

The "make wermit" steps do not pass on any macros except
the CFLAGS; they should.  Otherwise, things like "make
sunos4 CC=gcc" fail to work as expected.  All of the "make
wermit" lines in the Makefile should be extended with things
like "CC=$(CC)" etc.

------------------------------

Date: Fri, 17 Oct 86 15:17:14 EDT
From: Chris Maio <[e-mail]>
To: [e-mail]
Subject: telnetd "fix"

[Ed. - The following fix allows C-Kermit to work with 4.3BSD systems which are
accessed via TCP/IP-based terminal servers.  The fix is to TELNET, not Kermit.
Thanks to Chris Maio of the Columbia University Computer Science Department for
tracking down the problem and providing a workaround.]

This fix for /etc/telnetd in 4.3 BSD is really only a workaround, designed
to allow kermit, uucp, emacs, and other programs to receive carriage-return
chararacters over a "netascii mode" telnet connection where the client is
mapping carriage return to CRLFs (what I suspect to be the most common
case for terminal servers and non-UNIX telnet implementations).  The real
solution is to use telnet binary mode connections, but not all telnet clients
allow the user to negotiate this.

In /usr/src/etc/telnetd.c, routine telrcv(), line 640, replace

            c = '\n';
with
            c = '\r';

This fix is inappropriate if you have telnet clients which map CR into CR NUL,
and LF into CR LF, since those clients will then be unable to generate send the
linefeed character through to the application when CRMOD is turned off.  See
RFC 854 for more details.

The basic problem is that any program that manipulates the terminal will
generally only work right if the telnet connection is "binary mode" (remember
those odd commands you have to give to a TAC?).  Many telnet user interfaces,
including the terminal concentrators we use, don't provide a way for the user
to specify binary mode instead of netascii mode.  TOPS-20 is a lot smarter
about this kind of thing, e.g. it negotiates telnet binary mode when a program
running on a TVT specifies binary input from its controlling terminal, but
I'm sure there are still bugs in TOPS-20's implementation.

                        Chris

------------------------------

Date: 13 Sep 87 17:22:26 GMT
From: [e-mail] (Warren Burstein)
Subject: patches to ckermit
Organization: Industrial Automation Systems - New York, NY

These patches add to ckermit a "set phone" command.  Aliases are recognized in
the "dial" command.  My .kermrc is now full of set phone commands.

The new command looks like
   set phone pacx 280-8050
After this command, I can say
   dial pacx

I don't know how to make a "patch" file so here is a shar of all the diffs.

I am leaving the net in two days, I hope to be back on in a while and pick up
my mail from this machine.

I didn't use any fancy methods to store phone numbers, it didn't seem worth
the effort.

---------------
# This is a shell archive.  Remove anything before this line, then
# unpack it by saving it in a file and typing "sh file".  (Files
# unpacked will be owned by you and have default permissions.)
#
# This archive contains:
# ckudia.diff ckuus3.diff ckuusr.diff ckuusrh.diff

echo x - ckudia.diff
cat > "ckudia.diff" << '//E*O*F ckudia.diff//'
73,75d72
<  *
<  *   6-May-87  Support for phone aliases
<  *                            -- Warren Burstein
126d122
< char *malloc(), *strcpy();
422,431d417
<
< /*
<  * Array of phone aliases, unsorted
<  */
<
< #define MAXPHONES 100
< struct phones {
<     char *name, *number;
< } phones[MAXPHONES];
<
528d513
<     struct phones *lookup_phone(), *p;
530,537d514
<     if ( !isdigit(*telnbr))
<         if (p = lookup_phone(telnbr))
<           telnbr = p->number;
<         else {
<             printf("I don't recognize that system\n");
<             return -2;
<         }
<
866,927d842
< }
<
< /*
<  * Following code added by WB for phone aliases.
<  */
<
< /*
<  * Add a phone alias.
<  */
<
< add_phone(name, number)
< char *name, *number;
< {
<     struct phones *p;
<
<     /*
<      * If name is in use, redefine its number.
<      */
<     if (p = lookup_phone(name)) {
<         free(p->number);
<         p->number = malloc(strlen(number) + 1);
<         (void) strcpy(p->number, number);
<         return;
<     }
<
<     /*
<      * Find a vacancy in the table.
<      */
<     for (p = phones; p < &phones[MAXPHONES]; p++)
<       if ( !p->name) {
<           p->name = malloc(strlen(name) + 1);
<           (void) strcpy(p->name, name);
<           p->number = malloc(strlen(number) + 1);
<           (void) strcpy(p->number, number);
<           return;
<       }
<
<     printf("There are too many phone aliases.\n");
< }
<
< /*
<  * Returns phone number to use, or NULL if phone number could not be found.
<  */
<
< struct phones *lookup_phone(name)
< char *name;
< {
<     struct phones *p;
<
<     for (p = phones; p < &phones[MAXPHONES]; p++)
<         if (p->name && !strcmp(p->name, name))
<             return p;
<
<     return (struct phones *) 0;
< }
<
< shphones() {
<     struct phones *p;
<
<     for (p = phones; p < &phones[MAXPHONES]; p++)
<       if (p->name)
<         printf("%s %s\n", p->name, p->number);
//E*O*F ckudia.diff//

echo x - ckuus3.diff
cat > "ckuus3.diff" << '//E*O*F ckuus3.diff//'
268,280d267
<   case XYPHONE:
<     {
<         char name[30], number[30];
<
<         if ( (x = cmfld("name of phone alias", "", &s)) < 0) return x;
<         (void) strcpy(name, s);
<         if ( (x = cmfld("phone number", "", &s)) < 0) return x;
<         (void) strcpy(number, s);
<
<         add_phone(name, number);
<     }
<     break;
<
//E*O*F ckuus3.diff//

echo x - ckuusr.diff
cat > "ckuusr.diff" << '//E*O*F ckuusr.diff//'
436d435
<     "phone-number",     XYPHONE, 0,
473,474c472
< #define SHPHONE 2            /* phone numbers */
<
---
>
477d474
<     "phone-aliases",   SHPHONE, 0,
1085,1089c1082
<
<     case SHPHONE:
<         shphones();
<         break;
<
---
>
//E*O*F ckuusr.diff//

echo x - ckuusrh.diff
cat > "ckuusrh.diff" << '//E*O*F ckuusrh.diff//'
104c104
< #define XYPHONE 33                /* set phone alias - WB */
---
>
//E*O*F ckuusrh.diff//

exit 0

------------------------------

Date: Tue, 3 Nov 87 08:20:38 CST
From: munnari!adl.austek.oz.au![e-mail]
 (Richard Sharpe--Apprentice Sorcerer)
Subject: CKermit under Unix ...

We are having problems with ckermit on an Ultrix system (approx 4.3BSD).

We have kermit installed setuid and setgid to uucp to allow access to the UUCP
spool directory (to write the lock files). However, whenever kermit tries to
write files in the user's directories (perhaps because the user is running
kermit on the VAX in server mode and doing a send from a pc--mskermit), it
fails saying that it cannot open the file. If the user sets their directory to
world write, then ckermit on the VAX is happy.

Now, this seems to be an interaction between the way we have kermit installed
and what it is trying to do, but I cannot see any other way to set up kermit
so that it can reliably access the UUCP spool directory.

So, I checked out the code, and found that zopeno in ckufio.c just does an
open of the file that it is opening for output and then does a chown to the
real user and real group. I added the following code, and all seems to work:

   1. First pick up the real and effective UIDs.

   2. Then, just before the file open, set effective UID to back to our real
      UID.

   3. Then, just after the file open, set our effective UID back to what it
      was just before we changed it.

   Here is the code fragment that does it (lines with a * in col 1 are mine):

   zopeno(n,name) int n; char *name; {
*      int uid, euid;
       debug(F111," zopeno",name,n);
       if (chkfn(n) != 0) return(0);
       if ((n == ZCTERM) || (n == ZSTDIO)) {  /* Terminal or standard output */
       fp[ZOFILE] = stdout;
       debug(F101," fp[]=stdout", "", (int) fp[n]);
       return(1);
       }
*      uid = getuid(); euid = geteuid();
*      seteuid(uid);        /* Set us back to who is running kermit */
       fp[n] = fopen(name,"w");        /* A real file, try to open */
*      seteuid(euid);       /* And set things back to our SUID value */
       if (fp[n] == NULL) {
       perror("zopeno can't open");
       } else {
       chown(name, getuid(), getgid());     /* In case set[gu]id */
       if (n == ZDFILE) setbuf(fp[n],NULL); /* Debugging file unbuffered */
       }
       debug(F101, " fp[n]", "", (int) fp[n]);
       return((fp[n] != NULL) ? 1 : 0);
   }

  Now, as I say, this works, but I wonder if there is not a simpler way to get
this done, like only have kermit setgid to uucp. Would that be sufficient?

  BTW, this fragment came from version 4c(029) of ckufio.c. I also have
another version (ckcmai 4d(061) 8-Sep-86 and ckufio 4c(033) 8-Sep-86) but
there seems to be no changes in routine zopeno.

  Hope you can help me here.

Regards
Richard Sharpe
[e-mail]

------------------------------

Date: Wed, 4 Nov 87 09:54:09 CST
From: munnari!adl.austek.oz.au![e-mail]
 (Richard Sharpe--Apprentice Sorcerer)
Subject: CKermit under Unix ...

I have found problems with my solution that are to do with the differences
between sysV and 4.2 (I read about this setuid stuff in Bach's book), so I am
going to fix it up properly for SysV and 4.2/Ultrix. I also have access to a
MicroPort 2.2 system, so I will try to get it working on that system as well.
Finally, across the road is an NCR Tower, so I will try to get it running on
that.

When I do, I will ship you a copy of the changes. I may also try to fix the
problem where you wipe out the existing file if a send is aborted. However,
let me know if someone has already fixed this.

Regards
Richard

------------------------------

Date:     Mon, 1 Feb 88 15:23:59 EST
From:     Gary P Standorf <[e-mail]>
Subject:  #ifdef problem with ckuus3.c

When I tried compiling C-Kermit 4E(070) on an Intel-310 running
SCO Xenix 3.4 it blew up in the ckuus3.c module.  It doesn't like the
#include <termio.h> line which follows the #ifdef UXIII in ckuus3.c.
I added an #ifndef XENIX before the include for termio.h and then it
compiled ok.

PS.  I hope that doing an #ifndef was the proper thing to do, since I'm not
sure what other versions of XENIX need.

Thanks,

Gary Standorf
<[e-mail]>

-------

Date: 10 Feb 88 23:09:57 EST (Wed)
From: ames!netsys![e-mail] (Len Rose)
Subject: C-Kermit 4E(070) Sys V R3 vs ATT 3Bx

One little note to people setting up this on an ATT 3B2 running under
SYSVR3...  They have two options in the makefile that sort of clash when you
are bringing up this software.. You either have to choose:

make att3bx or make sys5r3

If you don't choose att3bx,the code does not look for the LCK..ttyxx in
/usr/spool/locks ... However if you choose att3bx,it does not handle signals
correctly...  All I did to defeat this was just put a #define in ckutio.c for
att3bx...  Just thought I'd pass this on, no big deal with it...

------------------------------

Organization: SMART HOUSE Limited Partnership
Phone: [phone]
Subject: C-Kermit 4F(085) on Xenix/386
Date: 21 Jul 89 12:10:05 EDT (Fri)
From: [e-mail] (John Owens)

I've tried out C-Kermit 4F(085) on SCO Xenix System V/386 2.2.3, and,
with one exception, haven't had any problems.  I've tried it in remote
and local mode, with extended-length packets, against itself and
MS-Kermit 2.32.

The one problem I had was with the disposition attribute handling:
Xenix doesn't have "unix" as a predefined symbol, and the mail/lpr
code is conditional on "#ifdef unix".  My quick fix is to add -Dunix
to all the XENIX makefile entries....  (I also vaguely remember either
POSIX or ANSI C having trouble with predefining "unix"; perhaps it's
the ANSI C draft that requires all predefined identifiers to have a
particular prefix.)  If you follow your note and move the routines
into a cku*.c file, this problem will go away.

Also, I'd like to suggest that, instead of receiving the file to be
mailed/printed then deleting it, that you open a pipe and receive into
it.  (I ran into this testing the "mail" feature while my current
directory happened to be one with mode 555!)

Oh, here's a note you might want to add to the .bwr file or something:

To use kermit with modems enabled for dialin under Xenix 2.2 (at
least), use the following procedure.  This example uses tty1A/tty1a
(the same device, with and without modem control).

% /usr/lib/uucp/ungetty /dev/tty1A
% kermit -l /dev/tty1a ...
 ...
% /usr/lib/uucp/ungetty -r /dev/tty1A

To do this one step better, find out (from your L-devices file) the
dialer program used for this device.  For example, if it were
/usr/lib/uucp/dialHA24 (the Hayes 2400 dialer), use:

% /usr/lib/uucp/ungetty /dev/tty1A
% kermit -l /dev/tty1a ...
 ...
% /usr/lib/uucp/dialHA24 -h /dev/tty1A 2400

(The dialHA24 program and friends do the ungetty -r for you.)

    Thanks for all the work you've put into this over the years....
    -John

------------------------------