The Atari Compendium/The Atari Compendium (Toad Computers) (1994).iso/files/prgtools/mint/utilit~1/tuu103d3.zoo/readme

Internet Message Format | 1993-01-07 | 15.1 KB

From: Juergen Lock <[e-mail]>
Subject: another test version of Taylor UUCP 1.03 for MiNT -- readme

[^^^ so you can reply easily]

here it is...  this is the current state of Taylor UUCP 1.03 on MiNT.
although it seems to work fine for quite a few people now i still regard
this stuff `beta', so don't expect it to work and don't try it unless
you know what you're doing. :-)

(sorry this readme does not tell you what uucp is and questions like
that.  if someone has or wants to write something of that sort he is
very welcome...)

what you need:

. MiNT 0.95 or newer, and a un*x-like shell that knows ARGV and can take
commands with -c. (_shell_p is *not* necessary. ;-)  you'll have to
either set $SHELL or put it in /bin/sh.

. if you have a fast modem or want to use error correction (MNP or
V.42...) then you most certainly will need a decent serial driver with
working RTS/CTS handshaking.  for modem1 i can recommend serialfx 1.0,
for modem2 and the others (tt/mega ste) i have yet to find one that
really works (see below).
 also enlarging the port's buffers helps keep the data flow when the
computer is doing other things while the uucicos are talking. (normal
size is 256 bytes each, i currently have them at 8K.)  and, whenever you
have error control (and unless the modems (telebit with spoofing on) or
the system you're talking to don't support that) you can always try
bigger `g' packets than the default 64 bytes.  don't believe people who
tell you the g protocol is inefficient, it's just the default of 64
bytes thats a holdover from the times when the fastest modems in the
world did 2400bps without error correction.  with 1 or 2 K packets
uucp-g is about as fast as a well-implemented zmodem... (and of course
*much* safer than all those jokes like uucp-e over async lines.)

. some sort of mail and news system (unless you only want to transfer
files.) but even then uucico needs a way to mail you about failed uucp
requests etc...  if it already has the usual rmail/rnews commands that
receive incoming work (on stdin) and knows how to call uux for
outgoing -- fine.  otherwise, if your stuff follows the `hamburg
standard' you can look at my `interface' in hh/...  and if you were
using the gfab*gsic uucico (descendant of mailtruk/mercury) you could
even try to keep your old uuxqt/whatever if you don't mind that it
(probably) doesn't do any locking or won't run very well in the
background.  to do that replace taylor's uuxqt with a script or something
that first `mv's all incoming files from /usr/spool/uucp/<system> into
/usr/spool/mqueue and then executes your old uuxqt.  or if your uuxqt
doesn't behave itself in the background try a similar script that first
calls uucico with -qD flags and then uuxqt.  (btw with -D uucico's
exitcode still doesn't tell you that a transfer failed... the easiest
way to find out for a script probably is uustat -m, or look at the
system's status in /usr/spool/uucp/.Status/<system> yourself.)
 if for some reason you want to keep an old uux (that you used with the
gfab*gsic uucico) then things get a little more complicated.  first,
depending on how it generates its filenames you probably can't use
(taylor's) uustat -k or -r on the jobs.  second, be careful with uuxqt
while there are still outgoing(!) *.x files in the spool directories,
uuxqt might think they are ment for the local system.  (if you can't
avoid that and need a way to distinguish between incoming and outgoing
files you could use the `Receiving site/Asomething.X' etc lines in
uucp's logfiles...  but fixing your uux of course would be easier.)
third problem could be the format of the command (*.c) files your old
uux or uucp (the command) write, if uucico then complains it can't find
files you'll have to patch that either in your uux/uucp or in uucico;
look at fsysdep_get_work() in sys4.c. (and do tell me what you did or
send me the diffs...)  if you just see funny names like `Sending
D._foo4711' in the logfiles don't worry, they are results of the
filename munging and as they name only local temporary files the remote
system should never use them.

. MiNT libs patchlevel 25 or newer (earlier versions not recommended
because there was a bug in readdir()), and a decent compiler.  well you
*can* get away by simply using my binaries, but i would always prefer to
compile it yourself because then you're not stuck with my compile-time
settings and you can help yourself (and me :-) when you find a bug or
something.  (and you need a not-too-old version of Larry Wall's patch
program to apply the diffs.)

. the original taylor-uucp-1.03.tar.Z archive (or how its called),
should be on any good GNU archive site. (even if you don't compile it
you still want the docs...)

what does not work:

. anything else than SPOOLDIR_BNU (#defined in policy.h).  GEMDOS'
stupid `CP/M-never-dies' filesystem (you know, 8+3 characters and only
one dot...) required severe hacks to the filename handling that were
only possible with SPOOLDIR_BNU. (or, maybe, SPOOLDIR_TAYLOR but i did
not implement that.)

. filenames starting with x:...  at least i did not look for problems
that might cause because you can always stay in MiNT's u: filesystem and
access everything from there.  (actually you *have* to be on u: or at
least set the rootdir in $UNIXMODE (ru) when you call one of the uu*
programs because otherwise they won't find things like /dev/null or
/dev/modem1 etc...)

. if someone tries to send you 2 files with identical names except case
(and you're not on a minix filesystem) then you will have a problem.  i
*could* hack around that at least for the usual temporary spool files
(i.e. uux jobs) but then you couldn't use an old uuxqt anymore.  (and
i did *not* want to start having uucico fumble around in incoming X.
files... :-( )  anyone have an idea?  otherwise i'll probably make it a
compile-time option some time.  (or is there really noone who wants to
keep his old uuxqt?  i mean i don't and taylor's certainly is better. :-)

. don't `mv' the names in /dev...  the serial port stuff i hacked to get
around MiNT 0.95's slow serial read() + write() and missing things like
carrier detect needs to know the BIOS device and currently the only way
to get that is thru ttyname().

. also i did not manage to get reliable transfers over /dev/modem2 (mega
ste) even after i fixed the usual round of atari-bugs in serptch2. if
you have better luck please tell me!  (on modem1 it works perfectly
well, its just that 19200bps is slower than what the modem can do with
V.42 and 16800 link speed...)  actually as it seems the real reason why
modem2 doesn't work on my mega ste is a *hardware bug*!  whenever the
chip that controls modem2 and serial2 (85c30 SCC, $ffff8c8x) is accessed
during DMA (disk access) i sooner or later have corrupted data either
to/from the disk(!) or the SCC. isn't that wonderful. :-( :-(

. the hacked-in 38400bps support for modem2 (thats only used when MiNT
and the driver itself don't know B38400...) always assumes 8bit no parity.
i.e. when you try to turn on parity it probably will not work or the port
will jump to a wrong speed.  if you really need that tell me, but as i
said modem2 is `broken' at least on my atari anyway. :-(

. theres also the chance that there are serial drivers out there that do
things different enough (buffer handling etc) so that my fastread() and
fastwrite() won't work.  if you suspect something like that and you
want to experiment you can change the #defines for MINT_FASTREAD and
MINT_FASTWRITE in sys2.c to 0; then it will always use MiNT's original
read and write.  tell me what you find out...
 similar if you're experimenting with modem2 and the DTR line does funny
things (you can see on the modem LEDs) or the port seems to be dead
after it sent a break or dropped DTR, then you might also have an
`incompatible' driver.  then try setting MINT_DTR and MINT_BREAK 0 in
sys2.c (see there for details).  or when there is a MiNT version that
supports B0 and TIOC[CS]BRK on modem2 you can do that too.

. hardware hacks that increase a serial ports speed and the driver
doesn't know(!).  uucico uses the bpsrate to calculate how long it can
sleep when it waits for buffers to fill or empty (to save CPU time), so
you probably won't get decent thruput unless you patch uucico so that it
knows the correct speed.  (look at fsserial_open() in sys2.c, adjusting
ibaud after the call to fsetterminfo should be the easiest way.  of
course if you have a portable method to detect the right speed you could
use that too...then send me the diffs. :-)

. compiling with a 16bit compiler.  or i would be surprised if that
worked without major fiddling... (but anyway gcc is free and its worth
the diskspace.  and if nothing else using gcc is certainly easier than
hunting for 16bit problems in a few 100 Ks of source. ;-)  also, i
almost forgot that, if you don't use gcc you will have to replace a few
__asm__ macros in sys2.c and in xchat, but that shouldn't be difficult
because they only do small things like raise ipl or call thru a vector.

. uustat -p doesn't work right because MiNT's ps doesn't have an option
to list only some processes (like ps -p pid).  anyone want to write
a `real' ps? :-)

. the original `make install' target. (or only if you have a very
un*x-like setup...)  i renamed it to install.ix and made a new one that
just copies and strips the executables.  (if you don't have xstrip don't
worry, it only removes the symbol table to save a few K disk space.  its
in gcc's binutils btw.)

what i have not yet tried: (tell me if it works...)

. all the stuff in contrib/ except xchat.  if you do and you had to
patch something, send me the diffs.

. incoming calls...  if you already have some sort of getty/login there
should be no problem, just make uucico the login shell like you would on
un*x. (i.e. set it up so that it runs uucico instead of a shell when the
other uucico logs in. stdin and stdout of course pointing to the port.)
 otherwise if you only want to take uucp logins you can also tell uucico
to prompt for login and Password itself (then it uses its own passwd
file).  but since it will certainly get confused when it sees modem
messages like RING or CONNECT (or...question: what happens when a modem
gets eg `watzman\rlogin: '? :-) you will have to either turn the
messages off (and use &d2 since the dialer might need them later) or try
a loop with some other program (xchat?) that answers the modem and waits
for carrier before calling uucico -l to accept a single login.  well one
of these days i should try...

. uucp over /dev/midi. (for a cheap method to network two ataris...)
the g protocol with small window and packet size (3*64? *) could work,
but probably not very fast.  problem is /dev/midi has no handshaking and
with the usual driver there's not even a send buffer.  oh and don't move
the mouse...
*: the window (in bytes) has to be smaller than the receiver buffer, ie
(packetsize + 6) * windowsize < bufsize. (you could call the window
uucp's `built-in' handshaking...)

 phew!  i hope all this stuff wasn't too boring. :-)  but it should
help when you know...

installation:

0. not strictly necessary but it helps:  set up a un*x like directory
structure for all the networking/uucp stuff.  of course directories are
more or less configurable for most programs but still you will save time
and worry when you use something like this
    u:/bin
    u:/etc            (`passwd' must be here)
    u:/tmp
    u:/usr
    u:/usr/bin
    u:/usr/lib
    u:/usr/local/bin
    u:/usr/local/conf
    u:/usr/local/conf/uucp
    u:/usr/local/lib
    u:/usr/local/lib/uucp
    u:/usr/spool
    u:/usr/spool/uucp
    u:/usr/spool/uucppublic    (or truncated to u:/usr/spool/uucppubl)
    u:/usr/tmp
    .
    .
(well you get the idea...  remember you can make symlinks in u:/)

1. unpack this and the taylor archive and read the docs.  (or of course
you can also read while it compiles... but at least you'll have to go
thru the part about the compile-time configuration first.)
 oh and if you didn't understand parts of the above maybe you will after
you have read the taylor docs...

2. cd into taylor's uucp-1.03/ directory and say
    cp conf.h-dist conf.h
    cp Makefile.in makefile
    cp sysh.unx sysdep.h
    cp sys1.unx sys1.c
    cp sys2.unx sys2.c
    cp sys3.unx sys3.c
    cp sys4.unx sys4.c
    cp sys5.unx sys5.c
    cp sys6.unx sys6.c
    cp sys7.unx sys7.c
 and then
    patch <this/directory/diffs
 after that is finished (should not report any problems or offsets) look
at conf.h, policy.h, sysdep.h and makefile to see if you have to change
anything for your setup.  (in conf.h probably only MAIL_PROGRAM, in the
others maybe some directories.  but note you don't need to change things
like /usr/some/thing into /c/foo/usr/some/thing because in that case you
can just as well make a symlink into MiNT's u:/ directory; that's what
they're for.)

3. now you can `make' and read the rest of the docs.  when its finished
you can try tstuu (see taylor's docs...except that at 8 MHz its probably
even slower than on a slow vax. :-)  oh and if it mostly works but the
wildcard requests fail its probably not uucp but your shell that has a
problem... there are creatures out there that don't even know what to
do with something like `echo /usr/tmp/tstuu/to6*'. :-(  (then either
get another shell or if thats not possible edit ECHO_PROGRAM in conf.h.)
 another shell-related problem could be the names of the chat
(shell-)scripts that tstuu uses.  because GEMDOS knows nothing about
execute permissions the shell must have its own idea about what files
are executable as scripts (that should be in your shell's docs).
i used .sh, if your shell wants something different change it. (i'm
using a port of a really nice pd kornshell in case you want to know.)

4. unless i forgot to tell you something important :-) you now should be
able to set up a connection to another system.  if you did not change that
in policy.h you can use taylor and hdb config files, all very much like
you would on un*x.  (there should be nothing that stops you from
enabling V2 config files too, except maybe the filenames that have the
dot in the `wrong' position for GEMDOS. so maybe you have to change that
to a _ or something...)
 if you prefer hdb you might find a hack i made to bnu.c useful: in
Systems after the device you now can not only set the protocol(s) but
also change the g parameters window, packetsize and (optional) timeout:

foobox Any ACU,g(7,1024t20) v19200 123456 "" \r\c ogin:-BREAK-ogin:-BREAK-ogin: nuucp word: nuucp
                 ^ ^^^^ ^^
 or (without timeout, default == 10 seconds)

foobox Any ACU,g(7,1024) v19200 123456 "" \r\c ogin:-BREAK-ogin:-BREAK-ogin: nuucp word: nuucp

 i don't remember where i saw that first but it certainly is a good
idea. (the timeout part is my addition.)  but remember the window
and packet parameters you set on one side always only control what the
*other* side is allowed to do, i.e. what your uucico *sends* still
depends on what the other end wants to have.

 ok and before i exit i'll tell you that as another example (there are
already a few in the taylor docs) you can look at my current config
files in usr/. (except Systems, for obvious reasons. :-)

 have fun...
    Juergen