VMS: logicals UNIX: links, but...

[Richard A. O'Keefe]

In article <2560 at cps3xx.UUCP> rang at cpswh.cps.msu.edu (Anton Rang) writes:
>One thing which *nobody* has yet pointed out is that VMS logical names
>can be (1) persistent, and (2) not just local to a process.

People who know VMS don't need to be told.
People who don't know VMS probably aren't interested in the discussion.

I don't quite follow what Rang wants the server example to do, mainly
because the implementation is described rather than the _problem_.
There is a problem with the proposed VMS hack:  what happens if Rang's
server smashes the FOOBAZ name in my group logical name table, and I
_also_ want to use Lazarus Long's server which _also_ smashes FOOBAZ?
For that matter, how do I run two copies of Rang's server at once?

The limited amount of IPC hacking I've done under UNIX has been managed
by having the client create a socket or a set of named pipes and shipping
the socket name or the names of the named pipes in the connection request.
(In the BSD world, don't overlook the possibility of passing file
descriptors in a message.)

>I would also like to be able to have a program which sets
>up environment variables.  This way, I could create a program (called
>'setup' perhaps) which would assign a default search path to my
>environment variable, and the user could type 'setup' to get the
>environment right before they ran the program.

It is usual for such programs to be shell scripts.  Here we have quite
a few such scripts; I can set up the "development" environment by doing
	. development		# Bourne shell
	source development	# C shell
You can also do things like
	eval `echo foo=1 baz=2`
where the command between the backquotes writes out a set of assignments.

By the way, it is straightforward to set up scripts like this which can
be sourced by either the Bourne shell or the C shell.  "development"
would look like this:
	test {a} = "{a}" && .  /usr/local/scripts/development.sh
	test {a} = a && source /usr/local/scripts/development.csh
The development.sh version contains lines like
	export foo; foo=something-or-other
and the development.csh version contains lines like
	setenv foo something-or-other
It works.

>  These arguments also apply to system-wide packages.  Suppose I
>install SuperPackage.  It wants an environment variable SPDIR to
>contain its search path.  Is writing a shell script to first set this
>variable, then run the package, the only way to make it accessible to
>users?  If so, what happens to the unsuspecting user who sets SPDIR to
>~/my_sp and expects it to look there?

If the author of the script for SuperPackage was any good, he wrote
	SPDIR=${SPDIR:-/the/default/value/if/unset/or/null}
or something like that in the script, and it _will_ look where the user
asked it to.  And no, shell scripts aren't the only possible answer:
aliases (C shell) and shell functions (Bourne shell) are two others.
Perl scripts are a third.

>As I said, my last posting (unless something here needs
>clarification.)  I think I have philosophical differences with some of
>the others discussing this.

The more I study MVS and CMS, the better I like VMS.  I think that when
the computer centre at my home University decided that they want to
replace their IBM painframe by VAXes running VMS they made the right
decision, and that UNIX wouldn't suit their needs quite as well.  (Most
of the departments that would benefit more from UNIX are already using
it.)  But simply bodging one of the messier features of one operating
system into another is _not_ a good approach to design.  The main
philosophical difference is that between "but I wanna do it *MY* way"
and "let's master the tools we've got before changing them".