V10/lbin/kermit/ckuker.bwr
C-Kermit Version 4E(070):
Status, Bugs, and Problems
As of: 4:23pm Wednesday, 23 March 1988
See ckuker.upd for a list of changes since the last release. 4E(066) was a
beta test release. It was tested at Columbia on various VAXes running Ultrix
1.2 and 2.0 (4.2 and 4.3 BSD equivalents, more or less), a Pro-380 running
2.9BSD, and an AT&T 3B20 running Sys V R2. The Unix versions need testing,
especially in local (dialout) mode on SUNs, PC's with Xenix, etc. During the
beta test, users reported that it worked on the Macintosh, on VAX/VMS (once a
the definition of syscleanup() was supplied in CKVTIO.C), on Xenix systems
once some extra #includes of "file.h" were removed, on the Pyramid once a
minor change was made to ckutio.c, and various other systems. 4E(067) just
applies these fixes, so that it can replace 4D(061) as the standard
distributed version. 4E(068) adds the ability to suspend Kermit on systems
with job control, plus support for the ATT 7300 internal modem, and
improvements to the C-Kermit server's handling of the 'remote cwd' command.
See ckuker.upd for details.
-- SUPPORT FOR DIFFERENT SYSTEMS: --
4.2BSD: "make bsd" works. Should work on VAX, SUN, Pyramid, Convex, & others.
4.3BSD: "make bsd" works.
4.1BSD: "make bsd" should work for this too (did not in C-Kermit v4.2).
2.9BSD: "make bsd29" works, at least on Pro-380. Should be the same for 2.8.
Version 7: works ok on the systems tested so far using "make v7", but some
fiddling with the make file is necessary for proc table definitions; see
the makefile and also ckuv7.hlp for details.
PC/IX: should work ok with "make pcix".
ATT 3Bx systems: should work ok with "make att3bx".
Xenix: This word no longer means anything specific. Is it an old Xenix that
looks like V6 or V7 Unix? Is it a System-V-like Xenix? Is it IBM's, or SCO's,
or somebody else's, and which Xenix version is it, and which compiler version?
Look at your system's documentation to see what's really hiding under the name
Xenix and use the appropriate make option. Usually 'make xenix' or 'make sys3'
work, so long as you're using the most up-to-date version of C-Kermit, 4D(061)
or later.
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.
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 att7300" as of 4E(068), to allow
operation with its internal modem and system support thereof.
Most other 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".
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 ckcfio.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>.
For other Unix systems, see the makefile, and for further notes, consult the
messages appended chronologically below.
VAX/VMS: support added by Stew Rubenstein at Harvard and Martin Minow at DEC.
Has to be built with CKV*.COM, needs development to handle all the VMS/RMS
features and to improve performance. See CKV*.*. VMS-specific bugs in
CKVKER.BWR. Somebody is working on upgrading the VMS support.
Macintosh: Support originally added at Columbia for SUMACC C cross
compiler. Has own makefile, etc. Adapted by Jim Noble of PRC to
compile under Megamax C directly on the Mac. See CKM*.*. SUMACC no longer
supported, only Megamax. In fact, the current code should not be used as
the basis of any development, because a very different new version is about
to be released, written in MPW C.
Commodore Amiga: Support added by Davide Cervone, U of Rochester, later
replaced (with Davide's consent) by new code from Phil Julian & Jack Rouse
of SAS Institute. See CKI*.*.
-- 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 --
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 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 reports a 1250% improvement doing this on
the TRS-80 Model 16!). Another speedup could come from allowing more
systems to take advantage of "myread()" -- the nonblocking version of
read(); see below. (4E fixes this to a great extent with rewritten ttinl(),
elimination of inlin(), etc.)
- 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.
- Need 'set' command for server timeout.
- 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.
- Speaking of conint(), it has been reported that there may be something
wrong with the way Unix Kermit responds to hangups. Although it traps
the SIGHUP signal and cleans up and exits when a phone connection drops,
some users report that the line is unusable after that.
- 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 get guaranteed exclusive access to a
communication is one of Unix's biggest shortcomings.
- There 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.
- The transaction log should record file type (text or binary).
- 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).
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...)
ckutio.c:
- Myread() should be expanded to include systems that can't do nonblocking
reads, but can find out how many characters are in the input buffer -- this
would eliminate calling read() in a loop for each character during packet
transmission (e.g. Pro/Venix V1 could use "ioctl(x,TIOCQCNT,&y)", V7 could
use its buffer-queue-peeking trick, etc). (Myread() was eliminated from
BSD, and the same technique is used as in ckucon.c -- do a single-char
blocking read, then check how many more chars are in the buffer, then read
that many -- it's faster.)
- There should be a timed option for ttoc() for use during connect so you
can escape from XOFF'd or other stuck conditions.
- 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.
- Use of RAW|TANDEM in 4.1 BSD gives only unidirectional, not bidirectional,
flow control -- xoff's from the terminal are treated as data rather than
control signals. Symptom: possible loss of characters during CONNECT.
- 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.
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.
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).
- 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").
------------------------------
Undigested:
Date: Sun, 24 Nov 85 04:16:02 CST
From: Stan Barber <neuro1!sob@rice.ARPA>
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 <abe@purdue-asc.arpa>
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
abe@asc.purdue.edu, ...!pur-ee!pucc-j!abe
------------------------------
Date: Fri 5 Sep 86 13:59:44-EDT
From: Fred Wang <OP.FRED@CU20B.COLUMBIA.EDU>
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: Fri, 12-SEP-1986 18:54 EDT
From: Kuryan Thomas <THOMASK@VTVAX5>
Subject: C-Kermit
To: fdccu@cuvmb
This is Kuryan Thomas at Virginia Tech again. I talked to you about the
modem problem I was having with my 6300plus. I think I found the problem --
tthang() does an ioctl() call to clear the CBAUD field, which ought to
cause a hangup. On my system, ioctl() doesn't like to be called with a
zero baud, and returns -1, which causes tthang() to return an error.
I think this may be why I always get a "Warning, problem hanging up the
phone" whenever I exit Kermit (regardless of the "set modem" setting).
I don't know how to cure this, but I'm not going to try. I think I prefer
the "aberrant" behavior. This way, I can start a session on a remote
Kermit, start its server, come back down to my shell, and start a long
file-transfer in the background. This wouldn't work if Kermit could
hang up the phone, because I'd have to use Kermit interactively. I often
transfer quite large files, and it's actually an advantage instead of a bug
that C-Kermit can't hang up my phone!
Amazing how problems can be turned to your advantage, isn't it?
Thanks for replying to my earlier message.
------------------------------
Date: Mon, 15 Sep 86 21:35:48 CST
From: rice!sob@soma.BCM.TMC.EDU (Stan Barber)
To: info-kermit@cu20b.columbia.edu
Subject: NEWUUCP conditional in C-KERMIT
You do need to define the NEWUUCP conditional to get the 4.3 acucntrl support.
Also, lock files are now kept in a seperate globally writable LCK directory
so unpriviledged programs can LCK lines without have write permission on
/usr/spool/uucp. This will keep uucp from stomping on kermit.
Stan
(NEWUUCP is currently not defined anywhere, so this code never gets used)
------------------------------
Date: Fri, 17 Oct 86 15:17:14 EDT
From: Chris Maio <chris@columbia.edu>
To: sy.fdc@cu20b.columbia.edu
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: Wed, 7 Jan 87 00:55:42 EST
From: nelson@NLM-VAX.arpa (Gary Nelson)
Subject: Xenix on IBM-PC/AT & SCO Xenix V
Keywords: Xenix, C-Kermit, SCO Xenix
In response to request for users of C-Kermit 4D(061) on SCO Xenix:
My configuration: IBM-PC/AT
SCO Xenix Release 2.1.3 (Update E & F)
The dial command did not work after updating to the release of SCO
Xenix V. The following diff file corrects problem in ckutio.c that broke
the dial command. Note, if you are on SCO Release 2.1.0 - DO NOT include
this fix, leave the 4D061 version as released alone - it works fine. The
nap() mod is not neccessary - just saw it and changed it to use an available
facility.
********** start of diff file **********
14a15,27
> /* Modification history:
>
> 23-NOV-86 Gary B. Nelson, Nelson Associates, Manassas, VA
> As a consequence of my new release of SCO Xenix V2.1.3
> breaking kermit:
> Mods to msleep to use nap(), note -> add "-lx" to
> LNKFLAGS in the makefile.
> Mods to tthang to make it work again, with this new release
> of XENIX (symptom was that the dial command
> stopped working, a problem that was incorrectly
> diagnosed by ?? as seen on the usenet a few days ago).
> */
>
527d539
< #ifndef XENIX /* xenix cannot do close/open when carrier drops */
532d543
< #endif
1416,1418c1427
< #ifdef XENIX
< #define CLOCK_TICK 50 /* millisecs per clock tick */
< #else
> #ifndef XENIX
1420d1428
< #endif
1431a1440,1446
> #endif
> #endif
>
> #ifdef UXIII
> #ifdef XENIX
> nap( (long) m );
> #endif
********** end of diff file **********
------------------------------
Date: Sat, 29 Aug 87 15:37 EST
From: <RICK@QUCDNAST.BITNET> (Rick Pim)
Subject: C-Kermit 4E Amiga .BOO File
Keywords: C-Kermit, Amiga
The Aug 7 info-kermit digest mentioned a new release of C-Kermit
for, amongst other things, the Amiga. According to the directory I looked
at of cki* *, the BOO file is new. The digest requested comments/etc, so I
ordered the BOO file and decoded it today. According to the header once
it's running, the version is 4D. It has at least one of the same bugs as 4D
(parity does not work).
[Ed. - Right, we don't have an Amiga .BOO file based on the new version yet.
We were hoping somebody would make one. See next message.]
------------------------------
Date: Wed, 12 Aug 87 10:25:42 pdt
From: cit-vax!ametek!walton@RUTGERS.EDU (Steve Walton)
Subject: C-Kermit 4E(066) on Amiga
Keywords: C-Kermit, Amiga
Well, I grabbed C-Kermit 4E(066) from CU20B, and have been able to compile and
link a running version on my Amiga using Manx Aztec C V3.40b. In the process,
I added the appropriate include files and the DOSFH and FILENO macros for Manx
C to ckiutl.c and ckitio.c; diffs will follow shortly. (One thing which was
easy: parity can be ignored in ttinl(), since the Amiga's serial.device
handles it itself, and passes characters to Kermit with the parity bit already
stripped.)
Stephen Walton, walton@ametek.UUCP
Ametek Computer Research Div.
610 N. Santa Anita Ave.
Arcadia, CA 91006 USA
818-445-6811
------------------------------
Date: Thu, 3 Sep 87 08:26:14 EDT
From: Marshall_DeBerry@um.cc.umich.edu
Subject: C-Kermit 4E Problems on Tandy 16A/6000 and Arete 1200
Keywords: C-Kermit, Tandy 16A/6000, Arete 1200
I've tried out the new 4E(066) release on a Tandy 16A/6000 and Arete 1200 under
System V.2. One problem I've noticed is that if you try to get the status
of the transfer, as soon as you type Cntrl A, the transmission begins to
send %T's, and eventually times out. This was during file transmissions
between the Arete and MTS Kermit. It was also reproducible between the
Arete and Tandy machines.
[Ed. - This sounds like something pretty specific to your machine; Ctrl-A
status reports work ok on the machines we've tested. I hope you can track it
down.]
The program compiled cleanly on both machines, except that on the Tandy end
(running under Xenix 3.1.2), I had to include <sys/types.h> for one of the
files in which void is used.
------------------------------
From: sob@watson.tmc.edu (Stan Barber)
Subject: C-Kermit Lock Files
Date: 20 Aug 87 21:26:17 GMT
Keywords: C-Kermit, Unix Lock Files
I should point out that C-Kermit(041) does handle lock files correctly under
BSD4.3 with the 4.3UUCP locking structure. This creates a lock directory
(/usr/spool/uucp/LCK) that is publically writable and each program (except
kermit) using the locking protocol is smart enough to test for dead locks
(coming from programs that aborted and did not remove its lock).
Stan
[Ed. - Presumably, this is also true for 4E?]
------------------------------
Date: 13 Sep 87 17:22:26 GMT
From: warren@pluto.UUCP (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
--
/|/~\~~\ The entire world Warren Burstein
|__/__/_/ is a very strange carrot.
| But the farmer philabs!tg!pluto!warren
/ is not afraid at all. Why doesn't life come with subtitles?
------------------------------
Date: Mon, 21 Sep 87 09:54:28 PDT
From: kevin@ACC-SB-UNIX.ARPA (Kevin 0'Gorman)
Subject: C-kermit 067 / UNIX PC
The comments in the makefile about AT&T 3bx machines DO NOT APPLY
to the 3b1. This machine uses the standard lock files. However, when using
the "shared libraries" (highly recommended) available on the UNIX PC, there
is a name conflict which makes it useful to add something like
-Dopeni=UPCOI -Ddial=UPCDIAL
to the cc command line. I accordingly create a new version, like the sys3
entry except for this addition. I call it unixpc, though upc would also be
familiar to UNIX PC hackers.
------------------------------
Date: Wed, 23 Sep 87 08:43:02 EDT
From: Marshall_DeBerry@um.cc.umich.edu
Subject: C-Kermit on Tandy 6000
Regarding your question about the Tandy 6000:
I am currently running 4D(061) kermit on such a machine with no
problems. My machine has 512K memory and a 15 Meg hard drive. It
runs at 6Mhz. I have not experienced any problems with "slowness",
as other's have often described. As a matter of fact, my machine is
in reality on old Model II that was upgraded to essentially a Model 16a,
which is my case is equivalent to a Model 6000 now. Anyway, the Xenix
that Tandy current supports is Xenix 3.1.2, which is pretty much like
system III. Note that all the versions of kermit I have compiled on my
machine have been done under Xenix 3.xx. The earlier version of Xenix that
Tandy put out for the first Model 16's was done from a version 7 Unix base.
I have had no expericence with the older Xenix. However, if you are using that
version, you really should pay the $99.00 to Tandy and upgrade to version
3.xx. (At least it was $99.00 about a year and a half ago).
Anyhow, to compile c-kermit on a 6000 under Xenix 3.xx, you need to do
two things:
1). Look in the source files for the use of identifier "void". If you
find that identifier in a file, make sure you put the include
line "#include <sys/types.h>" at the top of that file with the
other include statements.
2). Say make sys3, and wait awhile. If your system is fully loaded,
ie, about 90% full on the hard drive, and little memory, you may
not be able to compile the program. Make space on your hard drive
(down to around 75% free), and try again. It may take as long as
a half hour to compile.
Note that I recently compiled the experimental c-kermit (the "new release")
on a 6000 under Xenix 3.1.2 with no problems, save for the "void" identifier.
Also note that I am the only user of my machine, ie, I don't have other
users running out of tty ports. I can't tell you what running kermit
is like on a 6000 with 2-3 other users.
I hope this information is of help to Tandy 6000 owners trying to get kermit
up and running.
------------------------------
To: info-kermit@cu20b.columbia.edu
Subject: minor bug in c-kermit
Date: Thu, 01 Oct 87 23:52:57 EDT
From: moore@UTKCS2.CS.UTK.EDU
In C-Kermit 4E(067) 14 Sep 87, 4.2 BSD:
When compiling under Ultrix 2.0, using the vcc C compiler (which is slightly
better than pcc), C-Kermit doesn't compile cleanly, due the the existence
of several #ifdef vax11c lines in some of the .h files. These have been used
to denote VAX/VMS specific code. The vcc compiler pre-defines the symbol
vax11c on Ultrix just as it does on VMS. C-Kermit can be made to compile
cleanly on both Ultrix and VMS if these lines are changed to #ifdef vms.
Keith Moore
UT Computer Science Dept. Internet: moore@utkcs2.cs.utk.edu
107 Ayres Hall, UT Campus CSnet: moore@tennessee
Knoxville Tennessee BITNET: moore@utkcs1
------------------------------
Date: Wed, 21 Oct 87 22:20:18 EDT
From: cbmvax!vu-vlsi!devon!paul@RUTGERS.EDU (Paul Sutcliffe Jr.)
Subject: Diffs for C-Kermit 4D(061) and Tandy 6000
Keywords: C-Kermit 4D(061), Tandy Kermit
In Info-Kermit Digest V6 #23, I said I'd send the diffs along to compile
C-Kermit on a Tandy 6000. Here they are. Note that they assume that one is
running Tandy Xenix 3.0 or greater.
Install these diffs in the "stock" 4D(061) C-Kermit distribution, and then
type "make trs16" to compile. In reality, you only need to make the
modification to the makefile (ckuker.mak); the other diffs just make the
startup banner agree with the operating system version -- I didn't like
kermit saying "Xenix/286" on my 68000!
- paul
=========== CUT HERE ===========
*** .orig/ckuker.mak Fri Nov 21 16:04:08 1986
--- ckuker.mak Sun Jan 18 13:29:07 1987
***************
*** 226,231
"LNKFLAGS = -F 3000 -i"
#PC/IX, Interactive Corp System III for IBM PC/XT
pcix:
make wermit \
--- 226,237 -----
"LNKFLAGS = -F 3000 -i"
+ #Tandy 16/6000 with Xenix 3.0
+ trs16:
+ make wermit "CFLAGS= -DTRS16 -DXENIX -DUXIII -DDEBUG -DTLOG -DM_VOID -Dvoid=int -F 3000 -n" \
+ "LNKFLAGS = -F 3000 -n"
+
+
#PC/IX, Interactive Corp System III for IBM PC/XT
pcix:
make wermit \
*** .orig/ckufio.c Fri Nov 21 16:04:08 1986
--- ckufio.c Sat Jan 17 20:43:16 1987
***************
*** 63,68
/* Sys III/V, Xenix, PC/IX,... support by Herm Fischer, Litton Data Systems */
#ifdef UXIII
#ifdef XENIX
char *ckzsys = " Xenix/286";
#else
#ifdef PCIX
--- 63,71 -----
/* Sys III/V, Xenix, PC/IX,... support by Herm Fischer, Litton Data Systems */
#ifdef UXIII
#ifdef XENIX
+ #ifdef TRS16
+ char *ckzsys = " Xenix/68000";
+ #else
char *ckzsys = " Xenix/286";
#else
#ifdef PCIX
***************
*** 71,76
#ifdef ISIII
char *ckzsys = " Interactive Systems Corp, System III";
#else
char *ckzsys = " AT&T System III/System V";
#endif
#endif
--- 74,80 -----
#ifdef ISIII
char *ckzsys = " Interactive Systems Corp, System III";
#else
+ #ifndef TRS16
char *ckzsys = " AT&T System III/System V";
#endif
#endif
***************
*** 72,77
char *ckzsys = " Interactive Systems Corp, System III";
#else
char *ckzsys = " AT&T System III/System V";
#endif
#endif
#endif
--- 76,83 -----
#else
#ifndef TRS16
char *ckzsys = " AT&T System III/System V";
+ #endif
+ #endif
#endif
#endif
#endif
*** .orig/ckutio.c Fri Nov 21 16:04:09 1986
--- ckutio.c Sat Jan 17 20:44:47 1987
***************
*** 96,101
/* Sys III/V, Xenix, PC/IX support by Herm Fischer, Encino, CA */
#ifdef UXIII
#ifdef XENIX
char *ckxsys = " Xenix/286";
#else
#ifdef PCIX
--- 96,104 -----
/* Sys III/V, Xenix, PC/IX support by Herm Fischer, Encino, CA */
#ifdef UXIII
#ifdef XENIX
+ #ifdef TRS16
+ char *ckxsys = " Xenix/68000";
+ #else
char *ckxsys = " Xenix/286";
#else
#ifdef PCIX
***************
*** 104,109
#ifdef ISIII
char *ckxsys = " Interactive Systems Corp System III";
#else
char *ckxsys = " AT&T System III/System V";
#endif
#endif
--- 107,113 -----
#ifdef ISIII
char *ckxsys = " Interactive Systems Corp System III";
#else
+ #ifndef TRS16
char *ckxsys = " AT&T System III/System V";
#endif
#endif
***************
*** 105,110
char *ckxsys = " Interactive Systems Corp System III";
#else
char *ckxsys = " AT&T System III/System V";
#endif
#endif
#endif
--- 109,116 -----
#else
#ifndef TRS16
char *ckxsys = " AT&T System III/System V";
+ #endif
+ #endif
#endif
#endif
#endif
=========== CUT HERE ===========
Paul Sutcliffe, Jr.
UUCP (smart): paul@devon.UUCP
UUCP (dumb): ...{rutgers,ihnp4,cbosgd}!bpa!vu-vlsi!devon!paul
------------------------------
Date: Tue, 3 Nov 87 08:20:38 CST
From: munnari!adl.austek.oz.au!rsharpe@uunet.UU.NET
(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 onm 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
rsharpe%adl.austek.oz@uunet.uu.net
------------------------------
Date: Wed, 4 Nov 87 09:54:09 CST
From: munnari!adl.austek.oz.au!rsharpe@uunet.UU.NET
(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: Wed 4 Nov 87 09:40:00-EST
From: Frank da Cruz <SY.FDC@CU20B.COLUMBIA.EDU>
Subject: Re: CKermit under Unix ...
To: munnari!adl.austek.oz.au!rsharpe@UUNET.UU.NET
Sounds good. And no, nobody has sent in a fix for wiping out an existing
file when the transfer is aborted, and "warning" is off. Of course, if
people care about this, they should set warning on. But to be super nice
to them, I suppose Kermit could behave as though warning was on all the time,
i.e. give a new, unique name to an incoming file if another file by the
desired name already exists. Then, if the transfer finishes successfully,
delete the old file and rename the new one to the desired name. Otherwise,
delete the new file and keep the old one. - Frank
------------------------------
Date: Sun, 6 Dec 87 16:02 MST
From: <JRD%USU.BITNET@CUVMA.COLUMBIA.EDU> (Joe Doupnik)
Subject: CKermit bug in MAXL field w/Long pkts.
A small problem in CKermit 4E(067) 14 Sept 1987: when using Long
Packets the MAXL field in the initialization packet is incorrect. For example,
when the received packet size is set to 1000 bytes (Set Rec Pack 1000) then
MAXL is transmitted as a Control-H (8) and when the size is set to 997 bytes
then MAXL is Control-E (5). This indicates that somewhere the parameter rpsiz
is referring to the Long packet length rather than the desired size of regular
packets and tochar(rpsiz) is, of course, extracting the 8 bit remainder of
rpsiz + 32d. Curiously, manually overriding the startup length yields a correct
field for the initial S packet interchange with the server but an incorrect
value for the S packet interchange for a particular file.
In practice this has little effect because Long packet lengths are
used from their separate information and when they are not used the MAXL
field is correct.
Regards,
Joe D.
------------------------------
A user at NBS complained that the makefile does not work for building
C-Kermit from source on a PC/AT under Microsoft Xenix version 3.4B.
It compiled all the source files into object files, but did not link them
together into "wermit". After much experimentation, he found that he
could link the program manually:
cc -F3000 -i -o wermit <list of object files>
------------------------------
Date: 27 Jan 88 10:59 EST
From: junod@dtrc.ARPA (John Junod)
Subject: C-Kermit Timeout Problem Fix
Keywords: C-Kermit 4E(068)
The following code was developed about a year and a half ago by Mark A.
Thomas here at David Taylor Research Center to solve the time-out problem as
mentioned in the Info-Kermit Digest, V7 #3.
Hope this helps....
L. John Junod
junod@dtrc
/* The following fix was made in kermit to prevent the local machine from
timing out the terminal line. The local machine uses the last access time
of /dev/ttyXX to check for an inactive terminal. Fancy kermit i/o doesn't
update /dev/ttyXX while packets are sent/received. Since a packet doesn't
update the access time of the tty line, The local machine thinks the line is
inactive and times it out after 5-10 minutes. A call to the routine
check_time() is made in spack() and rpack(), and after 50 packets the tty
time is updated. 60 packets at 300 baud take about 5 minutes to send, so 50
packets is safe. */
/* included to fix local timeout problem */
#include "signal.h"
#include "sys/types.h"
#include "sys/timeb.h"
#define NULL 0x0
/* C H E C K _ T I M E -- Fix timeout during packet sending and
receiving. Since packets don't update the
tty access and modify times, we do it. */
check_time()
{
static char *tty_name = (char *) NULL;
static int i = 0;
char *ttyname(),*calloc();
struct timeb tbp;
time_t t[2];
if (tty_name == NULL)
{
tty_name = calloc(32,sizeof(char));
strcpy(tty_name,ttyname(0)); /* allocate and get tty name of stdin */
}
i++;
if (i > 50)
{
i = 0;
ftime(&tbp); /* get system time */
t[0] = tbp.time;
t[1] = tbp.time;
utime(tty_name,t); /* update tty time */
}
}
[Ed. - This would probably do the trick for BSD, but all the time stuff is
system dependent. BSD, Sys V, Xenix, Venix, V7, etc, have different ways of
getting the time. Meanwhile, this message has been added to the C-Kermit
"beware file".]
------------------------------
Date: Mon, 1 Feb 88 15:23:59 EST
From: Gary P Standorf <standorf@CECOM-2.ARPA>
Subject: Ifdef problem with ckuus3.c.2
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. I am including a context diff for your convenience.
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
<standorf@cecom-2.arpa>
---------------------------------------------------------------------------
*** ckuus3.c Mon Feb 1 14:58:01 1988
--- ckuus3.c.new Mon Feb 1 14:55:46 1988
***************
*** 20,25
#include "ckucmd.h"
#include "ckuusr.h"
#ifdef UXIII
#include <termio.h>
#endif
--- 20,26 -----
#include "ckucmd.h"
#include "ckuusr.h"
#ifdef UXIII
+ #ifndef XENIX
#include <termio.h>
#endif
#endif
***************
*** 21,26
#include "ckuusr.h"
#ifdef UXIII
#include <termio.h>
#endif
#ifdef datageneral
--- 22,28 -----
#ifdef UXIII
#ifndef XENIX
#include <termio.h>
+ #endif
#endif
#ifdef datageneral
-------
Date: Tue, 2 Feb 88 02:39:45 CST
From: Donn Baumgartner <donn@rice.edu>
Subject: bug/problem
version: 4e(70) [I think]
system: pc/ix
problem
description: compilation fails during link phase with unresolved reference
to _getcwd (and _end, but that doesn't count)
The problem is in ckufio.c, in routine zgtdir(); the #ifdef's there are
not correct for pc/ix (there, grouped with UXIII).
I have two fixes:
(1) just have the call return the (un-ifdef'ed) default, a pseudo
error message (it's something like "(undefined..."); not a
very elegant solution, but functional.
(2) I have programmed the berkeley-like call 'getwd' along with
supporting directory routines opendir, closedir, etc.; I did
these some time ago - they're well tested. You're welcome to
this source, if you like.
I have integrated the (2) solution into my copy; it's not clear whether
either solution is 'better', as I didn't notice how important that routine
was in the whole scheme of things...
cheers,
Donn Baumgartner
donn@rice.edu
-------
Date: Wed, 10 Feb 88 22:29:13 EST
From: rochester!ames!ucbcad!ucbvax.Berkeley.EDU!-
ucbcad!ames.uux!pur-ee!iuvax!bsu-cs!dhesi@columbia.edu (Rahul Dhesi)
Subject: Re: Unix Kermit Idle Line Problem
This is an answer to a query from nerd@percival.UUCP (Michael Galassi)
dated 28 Dec 87 00:42:59 GMT, in which he said that users using
"C-Kermit, 4C(057) 31 Jul 85, 4.2 BSD" are timed out for being idle
even though they are doing Kermit file transfers. Here is my
work-around as it was posted in a local newsgroup.
"By popular demand, here again is the technique for avoiding inactivity
timeouts when doing a long file transfer via Kermit.
Step 1. At the system prompt, give the command "tty". This command
will print your terminal name. It will be of the form /dev/tty15
where instead of 15 you will see the number of your terminal.
Remember it.
Step 2. Invoke Kermit interactively with the command "kermit" given
without parameters. (Actually you can give parameters too, so long
as they don't cause Kermit to begin data transfer immediately.)
When Kermit starts up and prints the prompt "C-Kermit", you go to:
Step 3. To Kermit, give the command "set line /dev/tty15". In place
of the 15, use whatever terminal number you obtained in Step 1.
Step 4. Now give Kermit the commands necessary to begin your file
transfer. You will not get an inactivity timeout.
Users who want to win fame on this system and the gratitude of others
can change Kermit so that the above sequence will not be necessary.
Currently Kermit uses the standard device /dev/tty which is synonymous
with your actual terminal. However, the operating system treats it
like a distinct device from your actual terminal. So, even though a
file transfer is going on using /dev/tty, the actual terminal, say
/dev/tty15, seems to be idle to the system, so you can get logged out.
This can be fixed by (a) finding the place where Kermit opens /dev/tty
and (b) replacing that with an open of the actual terminal name, which
can be obtained from the system call ttyname()."
Rahul Dhesi UUCP: {ihnp4,seismo}!{iuvax,pur-ee}!bsu-cs!dhesi
[Ed. - We'll consider this for the next release. Meanwhile, this message
has been added to the C-Kermit "beware file", CKUKER.BWR.]
------------------------------
Date: 10 Feb 88 23:09:57 EST (Wed)
From: ames!netsys!len@ll-xn.ARPA (Len Rose)
Subject: C-Kermit 4E(070)
Keywords: C-Kermit 4E(070)
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...
Len
[Ed. - Sigh, lock files again. There must be some better approach. Are
there any Unix experts out there who can suggest a better way to deal with
this problem, than requiring Kermit itself know the directory name, the
filename, the permissions, and the contents of the lock file on every version
of every Unix variant? Perhaps a separate program that runs Kermit in a
lower fork, or a program that Kermit runs in a lower fork. Of course,
separate programs have a way of getting lost...]
------------------------------
Date: Fri, 12 Feb 88 12:34:08 EST
From: David Herron E-Mail Hack <david@ms.uky.edu>
To: info-kermit@CU20B.COLUMBIA.EDU
Subject: Bug Report for C-Kermit 4E(070) on Unix PC (3b1)
I've gotten a copy of C-Kermit and am trying it out on various machines.
Mainly my Unix-PC since it's advertised to support the UnixPC.
First off, it wouldn't even compile right. In ckudai.c there is a "static
MDMINF ATT7300" which simply CANNOT be right. The problem is that you're also
using "ATT7300" as the pre-processor symbol to select UnixPC features, and it
has a null value, and the statement ends up looking like:
"struct mdminf = { ... };" which is a syntax error.
My workaround for the moment is to make all references to that symbol to be
"att7300" and make sure it's "static". The preprocessor on UnixPC's is of the
style that doesn't allow:
#define ATT7300 ATT7300
because it complains about macro recursion. (Oh, BTW, I'm running SYSV r3.51,
the latest version for Unix PC's).
Next, the makefile stuff for supporting the shared libraries is wrong. When
doing an ld to use the shared libraries, at least on Unix PC's, you pretty
much have to use ld directly like:
ld {some options} /lib/shlib.ifile {object files}
{more options} /lib/shlib
I may be off in a detail or two, but the point is that the way it was written
in the makefile was very wrong, as evidenced by all the multiply defined
symbols. Further, if I undo the stuff for the shared libraries I get
"tgetent" and a couple of other termcap functions as being undefined. And I
can't find those functions in any of the libraries on the system. What I
ended up doing was using a "cc" front end which handles loading the shared
libraries properly and has support for programs which use curses. It was
posted recently in unix-pc.sources and I could forward it to y'all if you
want. (It's the one named "ccc", there's at least one other of these
scripts).
Using "ccc" I got it pretty close, but there's a routine in /lib/shlib named
"openi" and there was a conflict between it and the one y'all had in ckcfns.c
-- the workaround here is to declare YOUR openi() to be static (which works
because it's not used in any other of your files), and don't forget to put a
"static openi();" at the beginning of the file as well. There's even a
section reserved up there for local variables.
Now I've got a program that compiles and loads without errors. In testing
some functionality:
I started with the remote kermit in server mode and transferred /bin/cat to
the remote (a 4.3bsd vax running kermit 4C(057)) and then got it back ("get
cat"). The result is a cat that is one byte shorter, but is otherwise exactly
the same. Now, this is a real neat trick too, 'cause it starts and ends with
the EXACT same bytes (I looked using od)! This shouldn't work out like this.
The new copy should be missing a byte at the end, but we've got the same byte
at the end. There isn't a byte missing in the middle 'cause "cmp" doesn't
find it, and if I "diff" the "od -c" output from each file, the ONLY
difference is the byte count at the very end.
I'm more than a little confused about that one ...
While the remote is in server, the local kermit acts rather strangely.
Possibly when doing ANY command, but definitely when doing send, get, and "!"
commands, to get back to command level from the command I have to type ^R ...
the only other character I've tried is <CR> which didn't get me back to
command level. Further, I once hit an empty line then started to do a shell
escape and it dumped me OUT of kermit and said something about an invalid
shell command. (an asice: There's times when I hate command processors which
read what I'm typing and complain before I get a chance to fix typing errors
...)
FINALLY:
In order to successfully connect to the modem and make a phone call I have to
enter this non-intuitive sequence of commands:
! rm /usr/spool/uucp/LCK..ph0
set line /dev/ph0
set modem att7300
set speed 1200
dial <phone number>
! phtoggle
dial <phone number>
If I don't remove the lock file first, the set line command of course will
complain about the lock file being there. But if I go ahead and phtoggle then
set line, the open in set line never returns and I hang. Then, there's some
other state where if I phtoggle the getty process that get started starts
looping -- that is, getty exits immediately causing init to start a new one
which exits immediately, and so on. Anyway -- I haven't tried it without a
dial command before the phtoggle yet.
I've got a kermit around here which'll let you do:
! phtoggle
set line /dev/ph0
set modem att7300
set speed 1200
dial <phone number>
just like you'd expect ... but it's an old copy that someone here made work
and then never told you guys about the changes. (ARGH!) Anyway, between the
two versions I should be able to get something working.
Oh, another problem when I exitted kermit ... I said "quit" and it waited a
little while and said "Problem with hanging up modem".
[Ed. - Unfortunately, we don't have any Unix PCs, or for that matter any
System III or V systems to test C-Kermit on, so we rely on people like
you to tell us what to do, or what we should have done. You're apparently
the first person who tried the new ATT7300 stuff, so thanks for the feedback
on that. But I haven't heard complaints from others about multiply defined
symbols, shared libraries, etc, and a lot of people are running this version
on System V, so I can only assume the problem there must be UnixPC-specific.
If you can send me a makefile entry that you have actually used with the
UnixPC, I'll be glad to replace the current one with yours, and add a hint
that if people have trouble w/other ATT Sys III/V based systems, they might
look at the ATT7300 entry for a model. If this is new stuff, then we have
a slight problem, because up till now (or at least up to Sys V R3), all
Sys III and Sys V C-Kermits could be compiled the same way.
Termcap??? There's nothing in Kermit that uses termcap or curses...
The other stuff will have to be looked in to. Thanks for the report. For
now, it's been added to the "beware file", CKUKER.BWR.]
------------------------------
Date: Wed, 2 Mar 88 17:23:47 EST
From: elsie!ado@ncifcrf.gov (Arthur David Olson)
Subject: MORE/bsd 4.3 (10/5/87) kermit does CR strips, not CR-LF->NL maps--w/fix
(This may be fixed in versions of C-Kermit later than version 4C(057), which
we're running.)
Description:
The kermit command strips all carriage returns, rather than
mapping CR-LF sequences to NL. This causes problems when transferring
(to the VAX) the output of programs that do underlining by outputing
a line of characters, doing a return, then outputing underlines in
the desired places.
Fix:
Note that even with this fix in place, if a file has a CR as its very
last character the CR will be (inappropriately) stripped. Then again,
we're not kermit gurus around here.
*** 1.1/ckcfns.c Wed Mar 2 17:17:32 1988
--- 1.3/ckcfns.c Wed Mar 2 17:17:43 1988
***************
*** 131,136 ****
--- 131,140 ----
/* Call with string to be decoded and an output function. */
/* Returns 0 on success, -1 on failure (e.g. disk full). */
+ #ifdef NLCHAR
+ static int sawcr;
+ #endif /* defined NLCHAR */
+
decode(buf,fn) char *buf; int (*fn)(); {
unsigned int a, a7, b8; /* Low order 7 bits, and the 8th bit */
***************
*** 158,172 ****
}
a |= b8; /* OR in the 8th bit */
if (rpt == 0) rpt = 1; /* If no repeats, then one */
- #ifdef NLCHAR
- if (!binary) { /* If in text mode, */
- if (a == CR) continue; /* discard carriage returns, */
- if (a == LF) a = NLCHAR; /* convert LF to system's newline. */
- }
- #endif
for (; rpt > 0; rpt--) { /* Output the char RPT times */
! ffc++, tfc++; /* Count the character */
if ((*fn)(a) < 0) return(-1); /* Send it to the output function. */
}
}
return(0);
--- 162,189 ----
}
a |= b8; /* OR in the 8th bit */
if (rpt == 0) rpt = 1; /* If no repeats, then one */
for (; rpt > 0; rpt--) { /* Output the char RPT times */
! ffc++; /* Count the character */
! #ifdef NLCHAR
! if (!binary) {
! if (a == CR) {
! if (sawcr == 0) {
! sawcr = 1;
! continue;
! }
! } else {
! if (sawcr)
! if (a == LF)
! a = NLCHAR;
! else if ((*fn)(CR) < 0)
! return -1;
! else ++tfc;
! sawcr = 0;
! }
! }
! #endif /* defined NLCHAR */
if ((*fn)(a) < 0) return(-1); /* Send it to the output function. */
+ ++tfc;
}
}
return(0);
***************
*** 424,429 ****
--- 441,449 ----
rcvfil() {
int x;
ffc = flci = flco = 0; /* Init per-file counters */
+ #ifdef NLCHAR
+ sawcr = 0;
+ #endif /* defined NLCHAR */
srvptr = srvcmd; /* Decode file name from packet. */
decode(data,putsrv);
if (*srvcmd == '\0') /* Watch out for null F packet. */
--
ado@vax2.nlm.nih.gov ADO, VAX, and NIH are Ampex and DEC trademarks
------------------------------
Date: Sun, 28 Feb 88 02:47:21 EST
From: hedrick@aramis.rutgers.edu (Charles Hedrick)
Subject: Results of Porting C-Kermit 4E and Fixes
Keywords: C-Kermit 4E
I just finished porting Kermit 4E to my Microport System V/AT. As usual,
simply typing "make sys3nid" (which is the setting for vanilla System V,
oddly enough) works correctly. It works correctly in the sense of building
a kermit that works the same as it works on other systems. Unfortunately,
the major new feature in 4E turns out not to work on any of the systems I
have access to. This is the long packet size feature. The two kermits
exchange information about what options they support. Unfortunately, the
code used for generating the byte that contains the capabilities appears to
be wrong. It results in having the systems say that they don't support long
packets. The expression is a long one involving several ? : constructs. My
C documentation does not make clear what the relative precedence of ? and |
should be. However both the Sun 3 and System V 286 compilers take the
opposite view from the authors of C Kermit. By adding a few ()'s, we avoid
the ambiguity. There was also a problem that the packet size sent for the
benefit of old systems that don't support long packets was miscalculated.
THey simply took the low-order byte of the full packet size. What they
wanted was MIN (packetsize, 94), 94 being the maximum size allowed by old
implementations.
The fixes are shown below.
This message is being sent to be info-kermit and the Microport newsgroup.
For the benefit of Microport users, let me note that Microport supplies a
fairly recent version of kermit with the system, version 4D. The version
being discussed here adds only the long packet support. (You might still
find it useful to get the files, since Microport doesn't seem to supply
documentation.) Kermit is available via anonymous FTP from
CU20B.COLUMBIA.EDU. The files you need are roughly ker:ckc*.*, ker:cku*,
and ker:ckw*, but ker:ckaaaa.hlp will give me information. Kermit is also
available at Simtel20. The index I have claims it is pd2:<unix.kermit>,
although today I was unable to get to those files to check them.
*** ckcfns.c.ORIG Sat Feb 27 19:25:03 1988
--- ckcfns.c Sun Feb 28 02:05:44 1988
***************
*** 607,613
CHAR *
rpar() {
! data[1] = tochar(rpsiz); /* Biggest packet I can receive */
data[2] = tochar(rtimo); /* When I want to be timed out */
data[3] = tochar(mypadn); /* How much padding I need (none) */
data[4] = ctl(mypadc); /* Padding character I want */
--- 607,616 -----
CHAR *
rpar() {
! if (rpsiz > 94)
! data[1] = tochar(94);
! else
! data[1] = tochar(rpsiz); /* Biggest packet I can receive */
data[2] = tochar(rtimo); /* When I want to be timed out */
data[3] = tochar(mypadn); /* How much padding I need (none) */
data[4] = ctl(mypadc); /* Padding character I want */
***************
*** 626,632
else
data[9] = '~';
! data[10] = tochar(atcapr?atcapb:0 | lpcapr?lpcapb:0 | swcapr?swcapb:0);
data[capas+1] = tochar(swcapr ? wsize : 0); /* Window size */
rpsiz = urpsiz; /* Long packets ... */
--- 629,635 -----
else
data[9] = '~';
! data[10] = tochar((atcapr?atcapb:0) | (lpcapr?lpcapb:0) | (swcapr?swcapb:0));
data[capas+1] = tochar(swcapr ? wsize : 0); /* Window size */
rpsiz = urpsiz; /* Long packets ... */
------------------------------