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