Path: utzoo!attcan!uunet!seismo!sundc!pitstop!sun!quintus!ok
From: ok@quintus.UUCP (Richard A. O'Keefe)
Newsgroups: comp.unix.questions
Subject: Re: VMS: logicals  UNIX: links, but...
Message-ID: <1006@quintus.UUCP>
Date: 17 Apr 89 02:34:56 GMT
References: <475@caldwr.UUCP> <810036@hpsemc.HP.COM> <1002@quintus.UUCP> <1604@blake.acs.washington.edu>
Reply-To: ok@quintus.UUCP (Richard A. O'Keefe)
Organization: Quintus Computer Systems, Inc.
Lines: 47

In article <1604@blake.acs.washington.edu> mtsu@blake.acs.washington.edu (Montana State) writes:

>How can Unix Environment vars provide all of the same features as VMS logicals?

They don't, they can't, and they shouldn't.
The _problems_ which VMS logical names solve can for the most part be
solved quite easily using existing UNIX mechanisms, that's the point
at issue.  Environment variables are part of it, so are links.

>In VMS most of the logicals can be set up as system-wide, such that every
>user has the logical in his environment.  There isn't any easy way for me
>to force a user to execute a startup script that sets up all of the
>environment variables for him.  

I'm sorry to disappoint you, but yes there is.  In fact, several ways.
In BSD-derived systems, there is a file /etc/gettytab (described in
man 5 gettytab).  Basically, to put the bindings X=a Y=b Z=c and so on
into everyone's initial environment, you add the entry
	:ev=X=a,Y=b,Z=c
to the default: entry in that file.  That isn't executing a startup
script, admitted, but it does set up environment variables.  Alternatively,
you could set the entry
	:lo=/usr/local/bin/mylogin
When getty has done its processing, it execs a program, which is normally
/bin/login.  'lo' overrides that.  Your program can add things to the
environment, and then exec /bin/login.  In _any_ UNIX system, you can get
the effect you want by editing /etc/passwd.  Where people have /bin/sh
as their shell, put /usr/local/bin/initsh.  Where people have /bin/csh
as their shell, put /usr/local/bin/initcsh.  Disable the 'chsh' command
(if you have it) so that users can't change it back.  Have the init*sh
programs set up the environment and then exec the corresponding shell.

I don't guarantee the gettytab method, never having been superuser to
try it.  My point is that instead of moaning about how UNIX wouldn't
let me do something, I spent 5 minutes looking through the manuals and
found how I _could_ do it (if I knew the right password...).

If you are content to _assist_ your users rather than _force_ them to
execute your script, there's an easy way.  First create a copy of your
setup script for each supported shell.  When you create a new account,
put the line
	. /usr/local/scripts/setup.sh
in ".profile" (which the Bourne shell sources at login) and put the line
	source /usr/local/scripts/setup.csh
in ".login" (which the C shell sources at login).  Do this to or for
existing users as well.  People who know what they are doing can take
the line out.