lukas@ihlpf.ATT.COM (Lukas) (10/14/87)
I hope that there is someone out there in netland that can help me to understand the hash function of sh. I thought that each command, as it was invoked, had its full path description evaluated (using $PATH) and placed in the hash list. Then, at future invocations, the path description could be gotton from the hash list rather than being reevaluated. This doesnt seem to be the case. I tested quite a few of my own commands (on two different machines) and it seems that the command location is reevaluted on each invocation. However, occasionally, the reevaluation does NOT occur, and I have not found out why, or how to predict the behavior. Also, all commands in the hash list have the "*" next to the "hits" data, again except occasionally. I cant determine what causes the "*" (which I think means "reevaluation") to be present or not, or how to control it. The absence of the "*" does NOT seem to be related to reevaluation (I have seen one that was reevaluated anyway; the new hash value had the "*"). Also, sometimes, after invoking a command, the hash list will be cleared. Future invocations of the same command do NOT clear the hash list. Sorry if this is all elementary (my dear Watson), but none of the reference materials I have do more than mention the hash. I am flummoxed. HELP! -- John Lukas ihnp4!ihlpf!lukas 312-510-6290
lukas@ihlpf.ATT.COM (Lukas) (10/23/87)
Thanks to Kevin Bond, Fred Christiansen, Ed Nieters, and Martin Davidson for their replys. I was informed that the hash behevior that I described was documented (sort of). So, seeking the last refuge of the incompetent :^) I RTFMd and found: The location in the search path where a command was found is remembered by the shell (to help avoid unnecessary execs later). If the command was found in a relative directory, its location must be re-determined whenever the current directory changes. This appearently means that having . in your $PATH causes any command path that follows . to be reevaluated on each invocation, to see if it is now in ., or elsewhere. I guess this makes sense, because the reason that I have . first in my $PATH is so that the directories over which I have the most control are searched first. More specifically, my $PATH looks like: .:`logdir lukas`/bin:/bin: etc. This allows me, for example, to have an ed that "remembers" the name of the last file edited, so that a simple succeeding "ed" will cause "/bin/ed last-file" to be invoked. Not earth shaking (except in California) I know, but its the little things . . . :^) This raises a couple of further questions: 1) Is this constant reevaluation of command paths more expensive than it is worth? (I detect no unacceptable degredation in interactive performance). 2) Is my thinking about the set up of my $PATH flawed? (Please no comments about the rest of my thinking) Is there a better way? 3) Is there any way (short of changing the path) to prevent the shell from reevaluating each command each time that it is invoked. This would be useful when creating a shell script that might loop through a series of commands a large number of times. Any further replies will be appreciated. How am I doing? -- John Lukas ihnp4!ihlpf!lukas 312-510-6290
stpeters@steinmetz.UUCP (Dick St.Peters) (11/04/87)
In article <2136@mcdchg.UUCP> lukas@ihlpf.ATT.COM (Lukas) writes: >reason that I have . first in my $PATH is so that the directories >over which I have the most control are searched first. More specifically, >my $PATH looks like: > > .:`logdir lukas`/bin:/bin: etc. For several years now, in my home directory on a fair number of machines around here I've kept a program named 'ls'. My ls doesn't do anything except warn people not to put . first in their path and record who tripped my trap. It's been interesting watching who I catch and how they react. (Every once in awhile, I catch myself when I do an rsh. Most embarrassing.) -- Dick St.Peters GE Corporate R&D, Schenectady, NY stpeters@ge-crd.arpa uunet!steinmetz!stpeters
schwartz@gondor.psu.edu (Scott E. Schwartz) (11/07/87)
In article <2269@mcdchg.UUCP> stpeters@steinmetz.UUCP (Dick St.Peters) writes: >My ls doesn't do >anything except warn people not to put . first in their path and >record who tripped my trap. > >It's been interesting watching who I catch and how they react. (Every >once in awhile, I catch myself when I do an rsh. Most embarrassing.) I once tried this. When my friends tripped across it they reacted like this: while (1) ls end and ran it in the background. I had things set up to mail me the notification of who I'd tripped. The above loop made sendmail so upset that the machine crashed. (at least the machine crashed a few minutes afterwards... causality was never really established and I never bothered to reproduce the crash.) -- Scott Schwartz schwartz@gondor.psu.edu