history idea

history idea

[Frederik Eaton]

Hi,

I have an idea for extending the usual shell history semantics.

It is to add a mechanism to zsh so that when the shell executes a
command, the command can communicate back to shell some lines which
should be added to the end of the history.

This would be useful in a number of ways. When working on the command
line we often enter and exit programs which provide new command-entry
"modes", from which a certain class of tasks can be accomplished
conveniently. This describes almost every interactive application: web
browsers, editors, mail readers, etc. But it would be nice to have a
record of the things that are done in these sub-modes, which is easily
available to the shell. For instance if I open a web browser with "w3m
http://some_url" and then while inside the browser I visit
"http://another_url", it would be nice to see "w3m http://another_url"
in my command history after the original "w3m http://some_url". Same
with files opened in an editor. It might not be so desirable for mail
readers, I don't know.

Of course, if you used such a feature, your history would become full
of crap that you'd never care about. Navigating it with
"{down,up}-line-or-history" after a long browser session would be
impractical. You'd have to switch to using the history search
commands.

The advantage is that you'd have a complete searchable record of
everything you do. I don't know what it's called, but I think
microsoft may have been working on something like this. I don't know
about the functionality of "google desktop" but some might be
included. Now, being able to search *inside* the web pages or files
you recently viewed is another matter, but implementing that would be
a lot easier if they were often listed in the shell history as I'm
proposing.

This would subsume web browser history, and a lot of other things.

To implement this, the shell could have an environment variable
pointing to a unix domain socket to which new history lines can be
sent.

(A point of detail. If a command wants to add to the shell history,
but it has been run by an intermediate command, then any extra history
lines it wants to add would be sent to the first shell above it in the
process tree... but something in-between should be able to intercept
and transform them. So for instance if you have a script which opens a
web browser (probably text-based) to do a google search for a given
term, and while you're in the browser you do several more searches,
then the browser process could communicate the browser command lines
corresponding to these searches to the script, which would rewrite
those URLs which corresponded to google searches into equivalent
invocations of itself, and pass them on to the shell... (i.e. changing
"w3m 'http://www.google.com/search?btnG=1&q=foo&hl=en&lr='" to "google
foo" if the script is named "google").)

Anyway, I hope this conveys the concept. Maybe it will never end up in
zsh but in any case I'd be interested to hear what people think.

Frederik

-- 
http://ofb.net/~frederik/

Re: history idea

[Bart Schaefer]

On Apr 27, 11:52pm, Frederik Eaton wrote:
}
} It is to add a mechanism to zsh so that when the shell executes a
} command, the command can communicate back to shell some lines which
} should be added to the end of the history.

This would be possible with a module.  The trouble is that it would
require that every command that wants to use it must also be modified
to perform the other end of the protocol.

A better (?) idea is similar to one the completion system already makes
use of:  Tell zsh how to parse the history files already maintained by
other apps, and add widgets (or configurations for a widget, e.g., the
completion functions) for pulling values from those files onto the zsh
command line.

That also avoids this problem:
 
} Of course, if you used such a feature, your history would become full
} of crap that you'd never care about. Navigating it with
} "{down,up}-line-or-history" after a long browser session would be
} impractical. You'd have to switch to using the history search
} commands.

Parsing the apps' own history files keeps each set of commands separate,
so that the true shell history doesn't get cluttered.