Danny, Thanks for the information. On Wednesday 01 September 2004 14:58, Danny Sauer wrote:
Randall wrote regarding '[SLE] BASH History' on Sat, Aug 28 at 10:07:
Hi,
The BASH history question reminded of a small problem I have with this function that perhaps someone can help me with.
I always keep a Konsole window open in which I have four regular interactive BASH shells and one root shell running.
When I log out or shut down, it seems that the four shells running under my user ID clash somehow or fail to coordinate in the way they write the history file, and I end up with only one of those shells' history.
Does anyone know of a way to get all four shells' worth of history saved?
Well, the problem here is described in the bash man page. I know, I know, man pages are too complicated for mere mortals to read (that's the gist I get from the list recently). So, as I consider myself well above mere mortal status, let me copy and paste. :)
Everyone's a comic...
On startup, the history is initialized from the file named by the variable HISTFILE (default ~/.bash_history). The file named by the value of HISTFILE is truncated, if nec essary, to contain no more than the number of lines speci fied by the value of HISTFILESIZE. When an interactive shell exits, the last $HISTSIZE lines are copied from the history list to $HISTFILE. If the histappend shell option is enabled (see the description of shopt under SHELL BUILTIN COMMANDS below), the lines are appended to the history file, otherwise the history file is overwritten. If HISTFILE is unset, or if the history file is unwritable, the history is not saved. After saving the history, the history file is truncated to contain no more than HISTFILESIZE lines. If HISTFILESIZE is not set, no truncation is performed.
...
If you want to solve that problem, the one possible "reliable" solution is to make the history file a named pipe, and run a daemon that manages sorting duplicates, etc. That wouldn't be *too* hard to write, but would be a pain none the less.
I can see how the saving could be done, but how would restoring work? BASH wants to read from that "file" (really a named pipe) now, and two readers of a named pipe just hang waiting for a writer.
You could play with the "shopt" builtin to change the history's features (or change variables before startup). The first thing that comes to mind is that you could set "histappend" so that each shell appends to the end of the existing history file rather than overwriting it. That would very likely save you, as the shell should append then truncate, and the other exiting shells (they do exit when you log out) would respect the file lock placed on the file when it's being manipulated by each shell in succession.
I'll work with the "histappend" option. It would be nice if it was implemented so only commands newly added to the history since that shell started up and it read the history file were appended to the history file upon termination. I'll run some experiments to see if that might actually be the case. If not, I think I can write some BASH code to "trap" the exit action and use the history command to manipulate the history so as to achieve the effect of "incremental histappend," if you will.
put a line that says shopt -s histappend at the top of your .profile / .bashrc and see if that helps. Turn on the "cdspell" option, too. It's cool. 'shopt -s cdspell'
Mmmm... I think I'd categorize that as "busybody ware." To each his own.
--Danny, who misspells stuff regularly :)
Randall Schulz (who spells well, but types too fast)