File specification regularity

Erland Sommarskog sommar at enea.se
Sun Oct 16 04:00:14 AEST 1988


Eric S. Raymond (eric at snark.UUCP) writes:
>In article <3981 at enea.se>, sommar at enea.se (Erland Sommarskog) writes:
>> On the other hand, on VMS you can do the following:
>> DEFINE/TRANSLATION=CONCEALED NEWS_ROOT SYS$SYSROOT:<UTILS.ANUNEWS> 
>> (This may be the wrong syntax. My apoligies if so.)
>
><chortle> Does anyone else see the funny here? The VMS syntax is so flinkin'
>obscure that you can't be sure you've got it right. 

As for the fun save the smiles. Unix often gives raise to questions
as what was that one-letter option again? And should the argument to the
option be separated with a space or not? The problem to remember the exact
form for a construct seldom used appears with any OS.  

>Compare the alphabet-soup
>VMS command above with the more-or-less equivalent UNIX link invocation:
>ln /usr/bin/utils/anunews /newsroot

Nothing wrong with links, and as long we only want /newsroot to point
to the same place all the time, it does the same job as the logical
name above.

But logcial names do more than so. Let's say that NEWS_ROOT above
in defined in the system table. (Which means that the name live until
the system dies. Preferably its definition is in the start-up file.)
Now I get a new version of NEWS which I like to experiment with before
I install it for everyone. In the logical-name table for my process
I define NEWS_ROOT to point were the new version lies. This definition 
overrides the system table, but for my process only. I could even say 
that NEWS_ROOT is a search list that points to many places. If a file
isn't found in the first directory it points to, the file system will 
look in the next one and so forth.
  Some of this, if not all, is surely available in Unix. But I fail
to intuitively see how symbolic links is the thing in these cases.
Enviroment variables come close, but, again, are they always supported?

>In a less facetious vein: which of the above requires less mental parsing,
>fewer interpretation rules with fewer exception cases? *This* is what Dave
>Arnold was getting at. Arguing that VMS's baroque syntax supports a feature
>UNIX doesn't isn't an appropriate counter, especially when you're wrong ;-).

Which naming scheme is the best is a discussion I rather stay out 
of. I wrote my article to point to that VMS actually doesn't require
you to write all that Dave Arnold claimed. It comes a no surprise
that Unix have an equivalent feature.
-- 
Erland Sommarskog            
ENEA Data, Stockholm         
sommar at enea.UUCP             



More information about the Comp.unix.wizards mailing list