Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > gnu.bash.bug > #14684 > unrolled thread

Re: Auto-update program cache feature

Started byEduardo A. Bustamante López <dualbus@gmail.com>
First post2018-10-03 18:33 -0700
Last post2018-10-03 18:33 -0700
Articles 1 — 1 participant

Back to article view | Back to gnu.bash.bug

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.


Contents

  Re: Auto-update program cache feature Eduardo A. Bustamante López <dualbus@gmail.com> - 2018-10-03 18:33 -0700

#14684 — Re: Auto-update program cache feature

FromEduardo A. Bustamante López <dualbus@gmail.com>
Date2018-10-03 18:33 -0700
SubjectRe: Auto-update program cache feature
Message-ID<mailman.1692.1538617051.1284.bug-bash@gnu.org>
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?

[toc] | [standalone]


Back to top | Article view | gnu.bash.bug


csiph-web