more csh path

matt%ucla-locus at sri-unix.UUCP matt%ucla-locus at sri-unix.UUCP
Tue Feb 28 12:02:59 AEST 1984


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

The problem I was addressing is that there are (at least) TWO environments 
when you are running in a shell script:

	- the environment provided by the user, which presumably
		should be transported outward to sub-commands
		(things like working directory, etc., especially).

	- the EXECUTION environment WITHIN the shell script; e.g.
		that which determines where a particular program is
		executed from.

The idea is that the search for the executable be done in one environment, 
and the execution occur in another.   Note that in distributed systems, 
there are multiple factors that affect searches (machine type, etc.) which 
could reasonably be put in one environment and not the other.

The mechanisms need NOT be as general as previously expressed; however,
there is certainly not a great deal of harm in it, as it provides rapid
extensibility.

So I am initially proposing a very simple change, namely, that a LOCAL 
EXECUTION environment be maintained by the shell, and that it be changeable
independently of the environment to be exported to programs invoked from
that shell.  This environment would be entered via a mechanism similar
to that proposed previously (e.g. a bracketed command).

A typical script might start with:
	[PATH = /bin:/usr/5bin:/usr/bin:...]
	[MACHTYPE = vax]
	...
These changes would not affect the EXPORT environment, but only the 
EXECUTION environment.    User programs would have the originally imported
environment, whereas EXEC's would search this alternate environment.

This separation would allow:
	- Stable shell scripts: library changes are masked (as before)
	- Understandable shell script interactions: environments do not
		change; the original user environment is available (not
		as before)
	- Porting: eased due to more consistent use of PATH mechanism 
		(although absolute bindings do have a place)

Although this mechanism provides a small advantage, it could be an
important one.

				- Matt



More information about the Comp.unix mailing list