Re: Are these bash.v.posix diffs still useful? They _seem_ dated...
On 2021/01/31 10:54, Chet Ramey wrote: On 1/30/21 6:50 PM, L A Walsh wrote: First behavior: How is it beneficial for bash to store a non-executable in the command-hash? Probably not very, but it's not all that harmful. The `checkhash' option overrides this. --- Does checkhash do anything other than correct these two cases where bash doesn't auto-correct an invalid entry in the hash of commands? Perhaps checkhash is no longer necessary either if bash removes the older functionality. Didn't think it was harmful other than being an opportunity to clean up something no longer needed. I believe one of the problems you listed with bash is that it was too big & slow. Surely eliminating unused/unneeded quirks would be a, albeit small, step in addressing that. Or are you arguing to keep cruft and unnecessary complexity where possible? ;^)
Re: Are these bash.v.posix diffs still useful? They _seem_ dated...
On 1/30/21 6:50 PM, L A Walsh wrote: Since this "https://tiswww.case.edu/php/chet/bash/POSIX; doesn't seem to be version specific, I'm assuming these are in the latest bash version. I don't understand the benefit of the differences involving hashed-commands and recovery behavior. It seemed like these behaviors may have served a purpose at one time, but now seem more likely to create an unnecessary failure case. First behavior: How is it beneficial for bash to store a non-executable in the command-hash? Probably not very, but it's not all that harmful. The `checkhash' option overrides this. What's really wasteful is to put something non-executable in the hash table when `checkhash' is set, only to remove it the next time you try to execute it. I changed that a few weeks back. And second, related behavior: Not searching for an alternative in the PATH if the old hashed value stops working. Again, `checkhash' covers this. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
Are these bash.v.posix diffs still useful? They _seem_ dated...
Since this "https://tiswww.case.edu/php/chet/bash/POSIX; doesn't seem to be version specific, I'm assuming these are in the latest bash version. I don't understand the benefit of the differences involving hashed-commands and recovery behavior. It seemed like these behaviors may have served a purpose at one time, but now seem more likely to create an unnecessary failure case. First behavior: How is it beneficial for bash to store a non-executable in the command-hash? And second, related behavior: Not searching for an alternative in the PATH if the old hashed value stops working. Is there a reason why the non-posix behavior should remain or might it be, perhaps, more desirable for the bash behavior to match the posix behavior?
