Path: utzoo!attcan!uunet!lll-winken!sun-barr!cs.utexas.edu!wuarchive!mailrus!ncar!husc6!cmcl2!panix!alexis
From: alexis@panix.uucp (Alexis Rosen)
Newsgroups: comp.unix.aux
Subject: uuxqt. The Mother of Invention. Fixed, at last.
Message-ID: <1990Sep30.195238.28564@panix.uucp>
Date: 30 Sep 90 19:52:38 GMT
Organization: PANIX - Public Access Unix Systems of NY
Lines: 87

(Like the saying goes, it sure was a mother...)

I and several others have in recent weeks complained about uuxqt's habit
of quitting in the middle of a large job. This was annoying, but I thought
I'd solved it by running it from cron every half hour. This is *DEFINITELY*
not the answer though- it will still toast your files fairly frequently. Of
course, I didn't find this out until Cnews had the grace to tell me there
was a problem.

Since Apple obviously can't write a working uucp (excepting Ron, who's not
distributing it), I decided to hack up a shell script that would deal with
both these problems. It does not need to be set{g/u}id to anything, and as
far as I can tell it works beautifully. However, I make *no gaurantees*. A
month ago I'd never written a real shell script... I guess I have at least
one thing to thank A/UX for - aside from those sleepless nights, I mean :-/

The strategy is simple. uuxqt never dies quickly- it must go through (it
seems, from watching many runs) at least 15 or 18 X files before it has a
chance to die. So I never give it a chance to die. I simply hide the X
files, and show them 10 at a time. I'm not sure but I think this may actually
speed up uuxqt if there's a lot of files in the spool (like, more than 300).
I also do some locking that is, as far as I can tell, 100% safe.

If anyone discovers any bugs, please mail to me as well as posting. After
all, if it is broken (unlikely though I think that to be), my news won't
be all that reliable...

Enjoy.

---
Alexis Rosen
very tired SYSOP/Owner
PANIX Public Access Unix Systems of NY
cmcl2!panix!alexis  or  alexis@panix.uucp

---------------------------->% cut here %<--------------------------------
#!/bin/sh
# uuxqt.wrap - V1.0 written by Alexis Rosen 9-30-90
# This bourne shell script is a wrapper for uuxqt which will prevent it from
# crapping out in the middle of a long run, almost certainly losing a file
# in the process. Rename the original uuxqt to uuxqt.real and change this
# file's name to uuxqt. This should be ownned/group by uucp, mode 770.
# It's too bad the guy who "fixed" uuxqt can't program to save his soul. I
# am absolutely disgusted with this. I just hope they get it right in 2.0.1!

cd /usr/spool/uucp
if [ ! -f X.* ] ; then exit 0 ; fi		# nothing to do

HIDEDIR=/usr/spool/uucp/hidden-x-files		# stick excess X files here

cd /usr/spool/uucp
if [ ! -d $HIDEDIR ] ; then mkdir $HIDEDIR ; chmod 770 $HIDEDIR ; fi

# check for a LCK.WXQT file. If it exists, see if it's stale or not.
# There is a very small window of time in which this locking system could
# fail. So wait ten seconds (probably way conservative) and inspect the lock.
if [ -f LCK.WXQT ] ; then
	kill -0 `cat LCK.WXQT` 2>/dev/null
	if [ $? != 0 ] ; then		# stale lock
		rm -f LCK.WXQT
	else
		exit 0
	fi
fi
trap 'rm -f LCK.WXQT /tmp/xw$$' 0 1 2 15
echo "$$" >LCK.WXQT			# make the lock

# Check the lock to make sure we kept it. If not let the other guy do the work.
sleep 10
if [ $$ != `cat LCK.WXQT` ] ; then trap 0 1 2 15 ; exit 0 ; fi

# Now move all the X. files into the hidden directory and then move 10 back
# out. When there aren't many X. files this won't matter but when there are
# hundreds, it's much more efficient than moving all but 10. Put the mv inside
# the loop to pick up any new X. files that might have just arrived.
while : ; do
	mv -f X.* $HIDEDIR 2>/dev/null	# all X. files into the hole
	ls $HIDEDIR >/tmp/xw$$		# make a list
	for i in `head /tmp/xw$$` ; do	# pull out first ten
		mv $HIDEDIR/$i $i
	done
	if [ ! -f X.* ] ; then exit 0 ; fi		# normal exit here

	/usr/lib/uucp/uuxqt.real $*	# fire up the real uuxqt
	XEXIT=$?
	if [ $XEXIT != 0 ] ; then exit $XEXIT ; fi
done