lcc.bob%ucla-locus@sri-unix.UUCP (02/27/84)
From: Bob English <lcc.bob@ucla-locus> Leaving the user's path intact and giving fully qualified pathnames can cause problems for the programs exec'd by the shell. Believe it or not, some programs actually assume that the program known as "foo" actually has a specific set of options which cause a specific set of actions, whether or not the name they give it is fully qualified. Short of eliminating pathname searches at any but the command level and requiring all programs to exec fully qualified load modules, you have to set the path yourself anyway. And I'd hate to try to move a bin directory on a system that had fully qualified pathnames hardcoded into ALL of its programs (user and system). Try adding /usr/sys5 to that and retaining soe measure of consistency. --bob--
matt%ucla-locus@sri-unix.UUCP (02/28/84)
From: Matthew J. Weinstein <matt@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
lcc.bob%ucla-locus@sri-unix.UUCP (02/28/84)
From: Bob English <lcc.bob@ucla-locus> I'm sorry, but your message makes little sense to me. While it's clear that you can switch back and forth between environments at the user level, and define some syntax to specify which one to use, it's not so clear how to make the facility available to user and program in a clear, well-defined manner without re-writing every program ever written. The problem is how giving the user the environment he wants whenever he is active without simultaneously blasting existing programs whenever he changes his path, not defining shell command syntax. --bob-- P.S. With multiple window support, or job control a la "csh" you can have environments running simultaneously anyway. Just start up a new shell, define your new enviroment, and visit at will.
matt%ucla-locus@sri-unix.UUCP (02/28/84)
From: Matthew J. Weinstein <matt@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
ras@rayssd.UUCP (03/08/84)
A while back, (on 4.1 BSD csh) I noticed a rather peculiar
phenomenon with the "cd" command and C shell variables;
If you happen to have a non-accesible directory by the name of one of
the variables, (such as "path", "cdpath", "home", etc.) in your current
directory, and you try and "cd" into it, you will actually end up in
the directory specified in the variable, for example:
% mkdir path
% chmod 007 path
% set path = ( /usr/local/bin $path )
% cd path
/usr/local/bin
% pwd
/usr/local/bin
This also happens on a non-existent directory, and does print
the directory that you landed in (a la cdpath).
I never bothered to find where this was going wrong, or if it was
just another feature, but was wondering if the same thing exists
in 4.2BSD.
--
Ralph Shaw, {allegra, decvax!brunix, ccieng5}!rayssd!ras
Raytheon Co, Submarine Signal Div., Portsmouth, RIrpw3@fortune.UUCP (03/10/84)
#R:sri-arpa:-1698600:fortune:26900030:000:956 fortune!rpw3 Mar 9 20:01:00 1984 No matter what you think of this "feature", the automatic dereferencing of shell variables in the context of a 'cd' command is at least documented, as the following edited excerpt from the man page shows: +-------------------- | cd | cd name | Change the shells working directory to directory name. | If no argument is given then change to the home direc- | tory of the user. | If name is not found as a subdirectory of the current | directory (and does not begin with `/', `./' or `../'), | then each component of the variable cdpath is checked | to see if it has a subdirectory name. Finally, if all ====> | else fails but name is a shell variable whose value | begins with `/', then this is tried to see if it is a | directory. +-------------------- Rob Warnock UUCP: {sri-unix,amd70,hpda,harpo,ihnp4,allegra}!fortune!rpw3 DDD: (415)595-8444 USPS: Fortune Systems Corp, 101 Twin Dolphin Drive, Redwood City, CA 94065