Re: Auto-update program cache feature
Chet Ramey wrote: > Bob Proulx wrote: > > Put this in your ~/.bashrc file and I believe your use case will be > > much happier. > > > > shopt -s checkhash > > How many installers put a new version of an existing package into a > possibly-different directory with a different name? Even using a symlink > pointing to a new name would not trigger this behavior. The use case (reading between the lines) had to do with ping-pong'ing between /usr/bin and /usr/local/bin though. And I know that without checkhash that I used to see that condition too. But with checkhash the complaint (from me) went away entirely. I admit I didn't look at it in great detail here now because I have had checkhash in use for so long and not seen this problem since. I'll need to experiment. Bob
Re: Auto-update program cache feature
On 10/6/18 4:23 PM, Bob Proulx wrote: > Jeffrey Walton wrote: >> I think a useful feature for Bash would be to automatically update the >> program cache after an install. > > Put this in your ~/.bashrc file and I believe your use case will be > much happier. > > shopt -s checkhash How many installers put a new version of an existing package into a possibly-different directory with a different name? Even using a symlink pointing to a new name would not trigger this behavior. -- ``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/
Re: Auto-update program cache feature
Jeffrey Walton wrote: > I think a useful feature for Bash would be to automatically update the > program cache after an install. Put this in your ~/.bashrc file and I believe your use case will be much happier. shopt -s checkhash In the bash manual: checkhash If set, bash checks that a command found in the hash table exists before trying to execute it. If a hashed command no longer exists, a normal path search is performed. I would prefer that to be a default. But it changed a behavior back in the day when it was added and deviated from the previous csh behavior. Therefore being an optional option makes sense. But I don't see a downside to defaulting to it now. In any case I always add it to my bashrc file. (Along with "shopt -s checkwinsize" too.) Bob
Re: Auto-update program cache feature
On 10/3/18 4:45 PM, Jeffrey Walton wrote: > Hi Everyone, > > I noticed a fair number of new Linux users have trouble with stale > program caches. Users install a package from a package manager or > sources and then are confused when the new package is not used. They > do not realize they need to run 'bash -r'; and most don't know where > to begin searching. OK, let's consider this. There are three cases: 1. A new program gets installed with the same name as an existing one, in the same directory. 2. A new program gets installed with the same name, but in a different directory in $PATH (and before the existing one). 3. A new program gets installed with a new name. (I'm putting aside the program deletion case.) You're saying that the seond scenario is most common, and common enough that we should develop a complex solution for it? I'd have to see more data before I'd accept that. -- ``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/
Re: Auto-update program cache feature
On Wed, Oct 3, 2018 at 11:20 PM Jeffrey Walton wrote: (...) > How Bash achieves it is an implementation detail left to the experts. > I made a few suggestions that don't seem to fit well. That's OK > because Bash internals is not my area of expertise. I think it's important to always consider the cost (in terms of implementation complexity and maintenance) of a feature we request from a free software program :) > Architecturally each instance of Bash is an object could receive a > "clear cache" message. How it is achieved does not matter to me. What > is important is, the right thing is done to relieve users from the > extra work for the common case. This paragraph contradicts what you said earlier. You keep suggesting that Bash should adopt this global message passing system where every instance of the shell can broadcast messages to each other... that is EXTREMELY complicated. Anyways, I should've read the manual before replying to this email thread. There's already a mechanism in place for what you want, it's the `checkhash' shopt.
Re: Auto-update program cache feature
On Wed, Oct 3, 2018 at 9:33 PM Eduardo A. Bustamante López wrote: > > On Wed, Oct 03, 2018 at 04:45:44PM -0400, Jeffrey Walton wrote: > > Hi Everyone, > > > > I noticed a fair number of new Linux users have trouble with stale > > program caches. Users install a package from a package manager or > > sources and then are confused when the new package is not used. They > > do not realize they need to run 'bash -r'; and most don't know where > > to begin searching. > > You mean `hash -r' ? > > > (...) > > so monitoring of common commands seems like a sensible way to > > implement the feature. > > > A single terminal can monitor for a regex that looks for 'make > > install' and perhaps other common installation commands. Multiple > > terminals seems like a trickier case, and could use a scheme where the > > source terminal broadcasts an 'update cache' message to other open > > terminals. > > A shell is not a terminal. A terminal is a hardware (or emulated) device that > provides input/output capabilities. Nowadays most terminals are emulated > (gnome-terminal, xterm, urxvt, ...), but there are still physical terminals in > use. It seems quite complicated to have all terminal emulators and physical > terminals introduce this functionality. > > And even if you manage to do that... how would that work? Terminals are only > aware of the input typed by the user, and the output provided by the programs > that run attached to that terminal device... that excludes a bunch of cases > like... How Bash achieves it is an implementation detail left to the experts. I made a few suggestions that don't seem to fit well. That's OK because Bash internals is not my area of expertise. Architecturally each instance of Bash is an object could receive a "clear cache" message. How it is achieved does not matter to me. What is important is, the right thing is done to relieve users from the extra work for the common case. > If you don't care about performance, why don't you just run `hash -r' through > PROMPT_COMMAND? That seems simple enough? This was answered in the problem statement: new users don't know what they have to do, and don't know where to go looking for the answer when things don't work as expected. It would be helpful if programs like Autotools and CMake finished with a prompt like, "Run 'hash -r' to tell users their next step but they don't. (It also would not help the multiple sessions case, but it would go a long way in helping users with the problem). Jeff
Re: Auto-update program cache feature
On Wed, Oct 03, 2018 at 04:45:44PM -0400, Jeffrey Walton wrote: > Hi Everyone, > > I noticed a fair number of new Linux users have trouble with stale > program caches. Users install a package from a package manager or > sources and then are confused when the new package is not used. They > do not realize they need to run 'bash -r'; and most don't know where > to begin searching. You mean `hash -r' ? > (...) > so monitoring of common commands seems like a sensible way to > implement the feature. > A single terminal can monitor for a regex that looks for 'make > install' and perhaps other common installation commands. Multiple > terminals seems like a trickier case, and could use a scheme where the > source terminal broadcasts an 'update cache' message to other open > terminals. A shell is not a terminal. A terminal is a hardware (or emulated) device that provides input/output capabilities. Nowadays most terminals are emulated (gnome-terminal, xterm, urxvt, ...), but there are still physical terminals in use. It seems quite complicated to have all terminal emulators and physical terminals introduce this functionality. And even if you manage to do that... how would that work? Terminals are only aware of the input typed by the user, and the output provided by the programs that run attached to that terminal device... that excludes a bunch of cases like: * Storing the command in a variable and then executing from the contents of that variable * Running a script that installs said binaries in a silent way ... Now, let's pretend you intention was to say that this logic should run in the /SHELL/, not the terminal. A shell only knows about the input provided by the user (through the terminal), for that specific process. So we still run into similar problems: * Binary is installed through a generic script Also, consider that bash runs in a multitude of platforms, each using their own package manager... it'd be a massive effort to gather all the possibilities into a table of patterns that you test user input against... and even if you do it, there are new platforms being introduced all the time, which means you'll have to update the table all the time to capture the new cases... that seems like a lot of work. If you don't care about performance, why don't you just run `hash -r' through PROMPT_COMMAND? That seems simple enough?
Auto-update program cache feature
Hi Everyone, I noticed a fair number of new Linux users have trouble with stale program caches. Users install a package from a package manager or sources and then are confused when the new package is not used. They do not realize they need to run 'bash -r'; and most don't know where to begin searching. I think a useful feature for Bash would be to automatically update the program cache after an install. Posix does not standardize an install command (cf, http://pubs.opengroup.org/onlinepubs/009696699/utilities/contents.html), so monitoring of common commands seems like a sensible way to implement the feature. A single terminal can monitor for a regex that looks for 'make install' and perhaps other common installation commands. Multiple terminals seems like a trickier case, and could use a scheme where the source terminal broadcasts an 'update cache' message to other open terminals. Some folks will argue that a person who installs a new program or updates an existing program does not want to use the newly installed program. They will argue it to the point it displaces the common case (with the common case being a user wants to actually use the newly installed program). For users who do not want to use the newly installed program a means to disable the behavior should be provided. Jeff
