uucp cleanup script (SysVr4.0)

[Lars Tunkrans]

woods at eci386.uucp (Greg A. Woods) writes:

>[I've cross-posted this to comp.bugs.sys5, since it is relevant to all
>SysVr4.0 versions....]

>In article <104374 at becker.UUCP> bdb at becker.UUCP (Bruce D. Becker) writes:
>> in Amiga Unix System V Release 4, version 1.1, there
>> is a misfeature in the "uudemon.cleanup" script:
>> 
>> 	SPOOL=/var/spool/uucp
>	^^^^^^^^^^^^^^^^^^^^^
>> 	[...]
>> 	cd $SPOOL
>> 	if [ "`pwd`" != "$SPOOL" ]; then
>> 		... mail error message to admin ...
>> 
>> This has been in the script for perhaps 5-6 years.
>>
>> It breaks under SysVr4 because "/var/spool" is a
>> symbolic link to "/usr/spool"; when the cd is done,
>> the working directory is now "/usr/spool/uucp" (at
>> least according to /bin/sh - ksh should succeed).

Below is a part of the uudemon.cleanup script from SVR4.0 on DRS6000 Sparc.

---------------------------
 
SPOOL=/var/spool/uucp

   {  stuff deleted }
 
#  cleanup funny directories that may have been created in the spool areas
cd $SPOOL
#  check that we are in the correct directory
if [ "`pwd`" != "$SPOOL" ]
then
	(echo "uudemon.cleanup: unable to chdir to $SPOOL") | mail $MAILTO
	continue
else
	for d in $SPOOL/*/*/*
	do
	if [ "$d" != "$SPOOL/*/*/*" -a -d "$d" ]
	then
		rm -fr $d
-----------------------------

 As you can see it's essentially the same as on Amiga.

>Ah, but the mis-feature is actually with the creature who built the
>filesystem.  /usr/spool should be a symbolic link to /var/spool, not
>the other way around!  /usr/spool is simply a convenience for well
>trained, but aging fingers.  /var/spool is what will be compiled into
>everything and, as we see above, specified in all scripts.

  I agree compleatly /usr/spool is the symbolic link to /var/spool.

>DOWN WITH EXCESSIVE SYMBOLIC LINKS!  They are a poor hack, and they
>cause way too much confusion....  They should only be used when it is
>*ABSOLUTELY* necessary to have a reference to file on a different
>filesystem, or *ABSOLUTELY* necessary to have multiple locations/names
>for a directory.  K.I.S.S.!

>Actually, why does /sbin/sh still have problems with pwd vs. sym-links
>in the first place?  I has no problems on SunOS-4.1.1.

>> The same problem exists for cd'ing to .Log directories,
>> since
>> 	VAR=/var/uucp
>> 	LOGDIR=$VAR/.Log
>> 	[...]
>> 		cd $LOGDIR/$i
>> 		if [ "`pwd`" != "$LOGDIR/$i" ]; then
>> 			... mail error message to admin ...
>> 
>> and "/var/uucp" is a symbolic link to "/usr/spool/uucp"...
>This is truly weird.  Why did they move the .Log directories into
>/var/uucp, instead of "leaving" them in /var/spool/uucp?  Why didn't
>they drop the silly '.' prefix from the name if they were moving them
>somewhere where they don't have to be differentiated from job
>directories?

 No not here, /usr/spool/uucp/.Log is a symlink to /var/uucp/.Log
All .directories are linked to /var/uucp/.directory   Presumably to 
separate the logfiles from the actual spooldirectories.
And to keep compatability with old software, it was nessesary to put in
the symlinks.

>Another extremely weird thing is that /etc/uucp is just a sym-link to
>/usr/lib/uucp, instead of containing sym-links to the administrative
>files in /var/uucp or /var/lib/uucp.  Actually, it seems that on
>SunOS-4.1.1 (which is where I presume the silly /etc/uucp idea came
>from), the actuall admin files (Systems, uudemon.*, ...) live in
>/etc/uucp, with a sym-link of remote.unknown to /usr/lib/uucp/remote.unknown,
>since it too has an admin function.

>Please, we don't need sym-links of everything admin-related into /etc!

No this is not the case either on DRS6000.  /usr/lib/uucp/Systems is a symlink
to /etc/uucp/Systems.   All the BNU/HDB config files are linked in this 
fasion to achive a situation were we have config data in /etc and program
files in /usr, in conformance with the overall philosophy for SVR4 which
is to keep out all but the nessesary binaries ( for system startup, i.e. mount
fsck a.s.o ) out of the root filesystem. 
The HDB binaries still live in /usr/lib/uucp,  uucico, uucheck and the scripts
Uutry and uudemon.xxx is found there.

>From what has been said above by Bruce and Greg it seems that Commodore has
symlinked the New directory-structure to the Old instead of symlinking the Old
directory structure to the New SVR4 directories. The symlinks are there to 
provide compatability for Old software. If one keeps the old directory 
structure intact and adds on symlinks to make the filestore appear as a
SVR4 filestore I sort of think that you have either misunderstood something
or just chosen the easiest way out of the fix. And because /sbin/sh finds out
where you really are it doesn't work either, as Bruce demonstrated.
 
   This is not intended to start a religious war about directories :-)
-- 
_______________________________________________________________________________
Lars Tunkrans  Phone +46 (0)76096368   DRS Systems Support
DOMAIN Address : lars at iclswe.icl.se    UUCP:  uunet!mcsun!sunic!iclswe!lars
X400: I=L;S=Tunkrans;OU1=SWE0102;O=ICL Data;P=ICL;A=TEDE;C=SE