more csh path

[matt%ucla-locus at sri-unix.UUCP]

From:            Matthew J. Weinstein <matt at ucla-locus>

Well, one possible solution would be multiple environments:  one for
the shell script, another exported to programs being executed, etc.
A syntactic mechanism would indicate which was to be used for evaluating
a particular command name (or maybe even file name); each environments
would contain such interesting values as working directory, variables, etc. 

The problem is making this easy to use.  Let's say we were to use a
leading set of []'s  on the command line to indicate that we want to
switch to a designated alternate environment. If you wanted to execute
some programs using the user's path, and some using your path, you might
start with:
	[PATH=/usr/5bin:/bin:/usr/bin]
Later on you want to do a cp, using your path, and a `bar', using the
user's path:
	[cp] foo bar
	bar
You could have done the `bar', and exported the new path as well
by doing:
	[export PATH]
before the:
	bar

Redirection, using an alternate working directory might be nice:
	[CWD=/usr/lib/foo/bar]
	sort baz [>bazfile]
This produces /usr/lib/foo/bar/bazfile, of course...

To make this practical, all values that can occur in the environment
(such as CWD, the current working directory, umask, etc.) would have 
to be named.  Clearly, the export'd environment could be a hodgepodge of
internal environments, but would default to the imported environment,
thus leading to little confusion.

Note that []'s are reasonable for the first char in a line; one hardly
ever does a pattern match there...  It's a little tougher midline, and
maybe an escape might be necessary.

Clearly an environment naming scheme, and a way of picking which 
environment is the alternate one, as well as their hierarchy, could 
be developed.  Even a two environment model, however, seems to resolve many
of the problems with minimal changes.

			- Matt