Xref: utzoo comp.unix.amiga:890 comp.bugs.sys5:1557
Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!wuarchive!ukma!widener!dsinc!bagate!cbmvax!amix!ford
From: ford@amix.commodore.com (Mike "Ford" Ditto)
Newsgroups: comp.unix.amiga,comp.bugs.sys5
Subject: Re: uucp cleanup script (SysVr4.0)
Message-ID: <2451@amix.commodore.com>
Date: 5 Jun 91 00:11:54 GMT
References: <104374@becker.UUCP> <1991May25.003224.5804@eci386.uucp>
Reply-To: ford@amix.commodore.com (Mike "Ford" Ditto)
Followup-To: comp.unix.amiga
Organization: Commodore-Amiga Unix Development
Lines: 89
Keywords: uucp /var /etc symlink
Summary: SVR4 uucp directories and symlinks explained, hopefully

In article <104374@becker.UUCP> bdb@becker.UUCP (Bruce D. Becker) writes:
> 	cd $SPOOL
> 	if [ "`pwd`" != "$SPOOL" ]; then
> 		... mail error message to admin ...
> It breaks under SysVr4 because "/var/spool" is a
> symbolic link to "/usr/spool";

In article <1991May25.003224.5804@eci386.uucp> woods@eci386.UUCP (Greg A. Woods) writes:
> 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!

Although it's true that the symlink would be more correct the other
way around, the bug is still in the script.  A script which depends on
the difference between /bin/pwd and the sh builtin is non-portable and
poorly written, IMHO.  The check in the uucp cleanup script is stupid
anyway because a failed cd terminates a script (and always has), and
even if it didn't, the script would be better written as:

	cd $SPOOL || { ... mail ...; exit ...; }

> DOWN WITH EXCESSIVE SYMBOLIC LINKS!  They are a poor hack, and they
> cause way too much confusion....

Hear, hear!

> 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.

I see no problems in sh that are not inherent in the concept of BSD
symlinks.

> This is truly weird.  Why did they move the .Log directories into
> /var/uucp, instead of "leaving" them in /var/spool/uucp?

To be consistent with the newfangled SunOS/SVR4 scheme:

	/var is for node-specific files that must be writable and may
	"grow" and need to be trimmed.

	/var/spool is for node-specific transient files that will be
	deleted after they are processed.

	/etc is for node-specific configuration files.

	/usr/lib is for shared, read-only, archetecture-specific
	libraries and programs.

Amiga Unix v1.1 had an unnecessarily non-standard uucp directory
setup and v2.0 will make much more sense.  A "proper" SVR4 uucp
directory setup has the following four distinct directories:

	/var/uucp
	/var/spool/uucp
	/etc/uucp
	/usr/lib/uucp

The only symlinks that should exist are the ones that cause files
that have been moved to a new directory also to be available under
their old names.

So, since Systems is now in /etc/uucp, there is
	/usr/lib/uucp/Systems -> /etc/uucp/Systems
but there is *NO*
	/etc/uucp/uucico -> /usr/lib/uucp/uucico
since uucico's official place is and always has been /usr/lib/uucp;
no program will expect it to be in /etc/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?

I don't know; I wish they had.

> 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.

/etc/uucp should have been a distinct directory but it shouldn't
contain any symlinks except for
	remote.unknown -> /usr/lib/uucp/remote.unknown.

					-=] Ford [=-

"The heart and the mind on		(In Real Life:  Mike Ditto)
 a parallel course, never		ford@amix.commodore.com
 the two shall meet."			uunet!cbmvax!ditto
 -- Indigo Girls			ford@kenobi.commodore.com