Xref: utzoo comp.unix.amiga:833 comp.bugs.sys5:1544 Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!think.com!zaphod.mps.ohio-state.edu!cis.ohio-state.edu!ucbvax!bloom-beacon!eru!hagbard!sunic!iclswe!lars From: lars@iclswe.icl.se (Lars Tunkrans) Newsgroups: comp.unix.amiga,comp.bugs.sys5 Subject: Re: uucp cleanup script (SysVr4.0) Message-ID: <1991May27.223106.3836@iclswe.icl.se> Date: 27 May 91 22:31:06 GMT References: <104374@becker.UUCP> <1991May25.003224.5804@eci386.uucp> Organization: ICL Data AB 194 85 Upplands Vasby Sweden Lines: 121 woods@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@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). 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@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