VMS: logicals UNIX: links, but...

[John Campbell]

>From article <16880 at mimsy.UUCP>, by chris at mimsy.UUCP (Chris Torek):
: In article <757 at mks.UUCP> tj at mks.UUCP (T. J. Thompson) writes:
:>Programs that read and write ``known'' filenames like this are simply
:>mis-designed.
: 
: Quite so.
: 
:>... it is true that some UNIX programs nonetheless do have built-in
:>file names (yacc, for example; i know not why).
: 
: Because their authors goofed.  `Well known' names and defaults are
:
: or the like.  If the author hard codes full pathnames *and* provides no
: way to override them, you may be out of luck, but this situation is
: comparable to someone hard coding specific file ID numbers in a VMS
: program.  Such a program should not be put aside lightly: it should be
: thrown with great force.

I remember being quite surprised to discover (as I was learning unix)
that common practice was to open full pathname entities on unix.  Instead,
of the nice abstraction that I was used to on VMS I found references to
/usr/dict/words, /usr/lib/tex/fonts, /usr/spool/uucp, etc.  This is
so common and osidious that I have both /usr/local and /local on my
3b1 at home because some silly-assed program referenced some data file
it needed as /local (whereas I like everything in /usr/local).

If you happen to work on a unix system without source you must adhere
to full pathnames (with *no* way to override them) for much of your
system.  /lib, /bin, /usr/ucb (why is this one on my SysV machine!!!)
etc. all seemed, when I started out, to violate my sensibilities.  Now
I'm afraid I've just given up and joined the "unix" camp...
-- 
	John Campbell               ...!arizona!naucse!jdc
                                    CAMPBELL at NAUVAX.bitnet
	unix?  Sure send me a dozen, all different colors.