[comp.unix.ultrix] ksh and x.25

marc@okeeffe.Berkeley.EDU (Marc Teitelbaum) (11/13/87)

Reply-Path:


I run an old version of ksh on ultrix 2.0 (and later) and the
problem with ksh is that ultrix went to dynamically allocated stdio
_iob's and ksh (non-portably) assumes static _iob's.  This is why
old 4.2 ksh binaries still work.  If you recompile, ksh will tromp
over anything which happens to sit after iob[3] (the last static
io buffer on ultrix).  The sleazy fix if you have source is to grab
a local copy of data.c (from /usr/src/lib/libc/stdio/data.c) and
stdio.h, and increase the number of static iobs from 3 to 20 (change
the #define _N_STATIC_IOBS from 3 to 20, and alter data.c to include
the local copy of stdio.h), i.e.  give ksh what it wants.  If it
doesn't work send me mail, or even call (oh god, an open invitation
to disaster).  I'm looking at the current 4.3+ BSD sources and i
don't see data.c anymore, and in fact it looks like 4.3 does the
noble deed of supplying 20 static iobs by default and malloc'ing
after that, so it doesn't look like 4.3 would have the problem. If
you don't have source you could try compiling ksh under an old
1.2 system or a 4.3 system and it might work (except ksh won't
understand NFS mounted directories). Or you might try recoding ksh
to not assume static iob's (the proper fix which requires real
work).  I believe the malignant routine is a local copy of fdopen()
in io.c of ksh source.

As for x.25, Ultrix has the f-proto in uucp and of course tip
works over any async port, so a PAD works just fine with these two.
I recommend the MICOM PAD, as thats what the software was tested with
when the f-proto was put in.  

Marc

--------------------------------
Marc Teitelbaum
457 Evans Hall		+1-415-643-6448
Computer Systems Research Group - CSRG/DEC
University of California
Berkeley, CA 94720