Xref: utzoo comp.unix.amiga:802 comp.bugs.sys5:1540
Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!uunet!zaphod.mps.ohio-state.edu!mips!apple!mauxci!eci386!woods
From: woods@eci386.uucp (Greg A. Woods)
Newsgroups: comp.unix.amiga,comp.bugs.sys5
Subject: Re: uucp cleanup script (SysVr4.0)
Summary: GRRR!  I don't like sym-links!
Message-ID: <1991May25.003224.5804@eci386.uucp>
Date: 25 May 91 00:32:24 GMT
References: <104374@becker.UUCP>
Reply-To: woods@eci386.UUCP (Greg A. Woods)
Organization: Elegant Communications Inc.
Lines: 67

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

In article <104374@becker.UUCP> bdb@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).

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.

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?

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!
-- 
							Greg A. Woods
woods@{eci386,gate,robohack,ontmoh,tmsoft}.UUCP		ECI and UniForum Canada
+1-416-443-1734 [h]  +1-416-595-5425 [w]  VE3TCP	Toronto, Ontario CANADA
Political speech and writing are largely the defense of the indefensible-ORWELL