From: Smylers Date: 17:31 on 04 Jan 2008 Subject: Bashing Bash Hashing I just spotted this in the README.Debian that Debian supply with Bash: bash does not check $PATH if hash fails bash hashes the location of recently executed commands. When a command is moved to a new location in the PATH, the command is still in the PATH but the hash table still records the old location. For performance reasons bash does not remove the command from the hash and relook it up in PATH. "For performance reasons"?!? The only way I can parse that is as claiming it's better to complain 'No such file or directory' than it is to run the command that the user asked for (and is in the path) because the former is faster. Really, do you expect me to buy that? Is that actually going to be useful to anybody? Use 'hash -r' manually or set a bash option: 'shopt -s checkhash'. Options make sense when different users genuinely have different preferences, not to make up for stupidities in your default behaviour. Smylers
From: demerphq Date: 18:09 on 04 Jan 2008 Subject: Re: Bashing Bash Hashing On 04/01/2008, Smylers <Smylers@xxxxxxx.xxx> wrote: > I just spotted this in the README.Debian that Debian supply with Bash: > > bash does not check $PATH if hash fails > > bash hashes the location of recently executed commands. When a command > is moved to a new location in the PATH, the command is still in the > PATH but the hash table still records the old location. > > For performance reasons bash does not remove the command from the hash > and relook it up in PATH. > > "For performance reasons"?!? > > The only way I can parse that is as claiming it's better to complain 'No > such file or directory' than it is to run the command that the user > asked for (and is in the path) because the former is faster. Really, do > you expect me to buy that? Is that actually going to be useful to > anybody? > > Use 'hash -r' manually or set a bash option: 'shopt -s checkhash'. > > Options make sense when different users genuinely have different > preferences, not to make up for stupidities in your default behaviour. Heh. I got bit by this hatefulness for the first time just yesterday. Very confusing. Its nice to hear I'm not the only one who finds this stupidity to be, er, stupid. :-) Yves
From: Walt Mankowski Date: 18:39 on 04 Jan 2008 Subject: Re: Bashing Bash Hashing --hQiwHBbRI9kgIhsi Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Fri, Jan 04, 2008 at 07:09:04PM +0100, demerphq wrote: > Heh. I got bit by this hatefulness for the first time just yesterday. > Very confusing. Its nice to hear I'm not the only one who finds this > stupidity to be, er, stupid. It's particularly hateful because when you run "rehash" to fix it, it returns instantaneously. I wonder if this is a case of premature optimization, or if it's a relic of bygone days when CPUs and hard drives were a lot slower. Walt --hQiwHBbRI9kgIhsi Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFHfn1YXfGeK2entYQRAlsEAJ9eWBSXfRcYo5AIU9itw7tu89omHACfXNn5 fjIjv08SGSEj3YOdi3YLjj8= =SuiZ -----END PGP SIGNATURE----- --hQiwHBbRI9kgIhsi--
From: Andy Armstrong Date: 18:43 on 04 Jan 2008 Subject: Re: Bashing Bash Hashing On 4 Jan 2008, at 18:39, Walt Mankowski wrote: > It's particularly hateful because when you run "rehash" to fix it, it > returns instantaneously. I wonder if this is a case of premature > optimization, or if it's a relic of bygone days when CPUs and hard > drives were a lot slower. I assume hash -r just discards the hash. The path search probably doesn't happen until the next time you type a command. And yes, having to manually delete the cash is bloody stupid.
From: Peter da Silva Date: 18:40 on 04 Jan 2008 Subject: Re: Bashing Bash Hashing Yes, this is one of those things that pisses me off about csh too. It's something that was done back when it was running on a PDP-11 and the four or five extra calls to namei() that you'd get when you typoed a command were significant on a machine with 70 users, 2MB of RAM, and big slow 14" disk drives. On the other hand if you get used to calling rehash when you change something in your path, you won't be confused when you put something earlier in your path (like, sticking a wrapper for "ls" in ~/bin) and nothing happens because it's still using /bin/ls. On the gripping hand, that's a pretty rare case, and the common case is hateful.
From: Michael G Schwern Date: 00:07 on 05 Jan 2008 Subject: Re: Bashing Bash Hashing Smylers wrote: > I just spotted this in the README.Debian that Debian supply with Bash: > > bash does not check $PATH if hash fails > > bash hashes the location of recently executed commands. When a command > is moved to a new location in the PATH, the command is still in the > PATH but the hash table still records the old location. > > For performance reasons bash does not remove the command from the hash > and relook it up in PATH. > > "For performance reasons"?!? > > The only way I can parse that is as claiming it's better to complain 'No > such file or directory' than it is to run the command that the user > asked for (and is in the path) because the former is faster. Really, do > you expect me to buy that? Is that actually going to be useful to > anybody? > > Use 'hash -r' manually or set a bash option: 'shopt -s checkhash'. > > Options make sense when different users genuinely have different > preferences, not to make up for stupidities in your default behaviour. Optimizing for the error case is hateful. Choosing a faster error that the user must correct manually over a slightly slower DTRT is an extra special hate. That there's no potential performance hit until AFTER IT'S ALREADY CLEAR THE OPTIMIZATION WILL RESULT IN AN ERROR is reserved for the naked, sweaty Dick Cheney having his way with you level of Hell. Of course, as Peter insinuated, I'm sure by now it's been rationalized as a "feature".
From: Phil Pennock Date: 00:33 on 05 Jan 2008 Subject: Re: Bashing Bash Hashing On 2008-01-04 at 16:07 -0800, Michael G Schwern wrote: > Of course, as Peter insinuated, I'm sure by now it's been rationalized as a > "feature". In large environments, having everything always locally available on local disk is fairly recent, with cluster management systems etc. NFS is still common. I'm in an environment where I work hard to keep my shell from having to go scan places in random NFS mounts, including syncing two-line shell wrappers to a special bin-dir within my NFS homedir since then at least if the dir cache gets flushed it's flushed by me, not by dint of someone somewhere always updating something. Heck, they go into aliases so the commands are only a backup for when scripts are invoking the command-name expecting it to be in the path. Without this grotesque hackery, regular work becomes nightmarish during the business day. Caches which don't cache negative results don't tend to be effective caches. The question is whether or not a cache should be used at all. So the feature is useful in some environments but probably shouldn't be the default these days. People in such environments can learn to use it and people whose idea of Unix is a single modern computer with local disks can't conceive of set-ups different from their own and whine a lot. Bloody Linux users. (zsh has a similar feature) -Phil
From: Michael G Schwern Date: 01:06 on 05 Jan 2008 Subject: Re: Bashing Bash Hashing Phil Pennock wrote: > On 2008-01-04 at 16:07 -0800, Michael G Schwern wrote: >> Of course, as Peter insinuated, I'm sure by now it's been rationalized as a >> "feature". > > In large environments, having everything always locally available on > local disk is fairly recent, with cluster management systems etc. NFS > is still common. > > I'm in an environment where I work hard to keep my shell from having to > go scan places in random NFS mounts, including syncing two-line shell > wrappers to a special bin-dir within my NFS homedir since then at least > if the dir cache gets flushed it's flushed by me, not by dint of someone > somewhere always updating something. Heck, they go into aliases so the > commands are only a backup for when scripts are invoking the > command-name expecting it to be in the path. Without this grotesque > hackery, regular work becomes nightmarish during the business day. > > Caches which don't cache negative results don't tend to be effective > caches. The question is whether or not a cache should be used at all. > > So the feature is useful in some environments but probably shouldn't be > the default these days. People in such environments can learn to use it > and people whose idea of Unix is a single modern computer with local > disks can't conceive of set-ups different from their own and whine a > lot. Bloody Linux users. > > (zsh has a similar feature) I think you've veered off into a wholly different and more subtle hate. We're not talking about not caching negative results, as in "there was a command called 'foo' at /path/to/foo and now it's gone. I didn't find it the last ten times I scanned PATH but maybe the eleventh will work!" For that, caching the time of the last negative result would be handy, then you could at least do a progressive back off. Even so, it only effects performance when you try to run the missing command. We're talking about "there was a command called 'foo' at /path/to/foo and now /path/to/foo is gone. Well, that's the best I can do, I give up. You're welcome to blow away THE ENTIRE CACHE and I'll rescan EVERYTHING for you. k thx bye!" I would think that would generate maximum hate in a slow environment. And, of course, WHY IS THIS STILL THE DEFAULT?!
Generated at 10:27 on 16 Apr 2008 by mariachi