post-diluvian shells

[fivemack]

Is there any shell which maintains an at-all-sensible command history when you're working with several terminals each with half a dozen sessions in tabs? Intercalating the history from multiple sessions would probably be ideal for my current working style; appending the history from each session as a lump when the session closes would also be fine; but at the moment tcsh seems to maintain history for at most one session, randomly-selected, and this makes 'history' less than useful if I actually want to work out what I've been doing.

Comments

[senji.livejournal.com]

The galeïan in me is shouting "zsh" at this point.

I don't actually use it myself though.

[ewx.livejournal.com]

I believe Bash appends its history as a lump when you close it.

[senji.livejournal.com]

met24's description fits better, I'm afraid.

I'm actually considering having per-{STY,WINDOW} history files for this reason.

[ewx.livejournal.com]

I suspect the problem is that it doesn't get to write the history if it doesn't get to shut down gracefuly.

[senji.livejournal.com]

I think it also fails to lock sensibly, such that you get problems if two bash quit at once.

[dd-b.livejournal.com]

If it is, I am experiencing the same hallucinations.

zsh

[http://the.earth.li/~alex/halley/ (from livejournal.com)]

zshzshzshzshzsh

APPEND_HISTORY or
INC_APPEND_HISTORY or even
SHARED_HISTORY

are friendly type options.

[arnhem.livejournal.com]

I wouldn't dream of doing anything that sounded remotely like recommending that someone start or continue working with the csh or its derivatives, but have you noticed the bit of the manual that asserts that the "savehist" shell variable can contain two words - the first, if set to a number, says how many lines should be saved in the history file; the second, if set to "merge" causes the history list to be merged with the existing history file instead of replacing it, and sorted by time stamp.

It does note, depressingly, that this only works "when the shells quit nicely one after another", so I suspect that the quite common behaviour of killing an X session resulting in a whole bunch of shells quitting almost simultaneously will just result in corrupted history files ...

Worth trying

set savehist="10000 merge"

as a quick fix, allowing for the fact that there are known failure modes?

[ewx.livejournal.com]

You wouldn't have thought it was that hard to write a little history management library that did the right thing. Might be trickier persuading shell maintainers to integrate it...

I think you'd need the following operations:

• Use the following history file
• Give me the N most recent history items as an array of strings
• Add these lines to the history
• Get/set the maximum history size
• Err ... that's it?

Any number of processes can use any of the operations in any order and it's still safe. It'd have to be safe over NFS too, which might be more entertaining.

There'd also be little command, again using this interface, to separately set the history size, for integration with applications that lacked a convenient way to configure it.