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? Randall Schulz
On Saturday 28 August 2004 17:07, Randall R Schulz wrote:
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?
Perhaps the history is only saved if you logout of each shell properly, i.e. with 'exit', or 'logout'. Try to kill a shell on a virtual tty console (e.g. <Alt>+<Ctrl>-<F2>), and see if the history is saved. ;) Cheers, Leen
Leen, On Saturday 28 August 2004 13:33, Leendert Meyer wrote:
On Saturday 28 August 2004 17:07, Randall R Schulz wrote:
Hi,
...
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?
Perhaps the history is only saved if you logout of each shell properly, i.e. with 'exit', or 'logout'. Try to kill a shell on a virtual tty console (e.g. <Alt>+<Ctrl>-<F2>), and see if the history is saved. ;)
I don't know the precise means by which the shells are shut down when Konsole is shut down during a logout, but one shell's history always ends up being saved. Manually shutting the shells down is counter-productive, since then when I log in the next time, I wont' have my shells ready to go and I'll have to manually restart them (and rename them, as is my wont). If that's the alternative, then I'll just use some scripts I already have for resetting the shell context to its initial (login) state, which also saves the history. I'll have to remember to do it, but I guess that's the same thing if I have to terminate the shells to get their histories saved.
Cheers,
Leen
Randall Schulz
On Saturday 28 Aug 2004 16:07, Randall R Schulz wrote:
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?
Randall Schulz I have found i get no such problems using xterm i get full history in each term that goes way back ..
Xterm may not have the fancy multi window in one place stuff but is by far the best of the bunch Pete . PS . joe blows all other editors away as well . -- Linux user No: 256242 Machine No: 139931 G6NJR Pete also MSA registered "Quinton 11" A Linux Only area Happy bug hunting M$ clan PGN
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. :) 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. In the reading of that section, it becomes clear what's happening. Each of the shells that your kterm starts reads the history file when it starts up. Then, it stores the commands in memory until it exits. At the time of exit, it creates a new history file containing the last 500 entries in memory. What you have is 4 shells that have the same last 500 lines when they start, but then each one adds only to its in-memory list. The lines that are saved, therefore, can only be those that are in the list of the last one to exit, and it has no idea what the other shells might have put in the file when they exited. 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. 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. 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' --Danny, who misspells stuff regularly :)
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)
Randall wrote regarding 'Re: [SLE] BASH History' on Wed, Sep 01 at 17:27: [...]
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.
I was just presuming that the shell obtained an exclusive lock on the history file for readnig - which would be relatively important in the case where one shell's exiting and overwriting the history at the same time another shell is starting. Admittedly, I didn't look into that... Doing a little testing, I guess multiple readers from a named pipe is not a good idea. :) You could still do the one-pipe-per-shell thing with the environment variable, though. Wait, that'd be awful. If you do that, don't let anyone know that I suggested it. I need to wash my keyboard after such a suggestion. --Danny
Danny, On Thursday 02 September 2004 13:57, Danny Sauer wrote:
Randall wrote regarding 'Re: [SLE] BASH History' on Wed, Sep 01 at 17:27: [...]
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.
I was just presuming that the shell obtained an exclusive lock on the history file for readnig - which would be relatively important in the case where one shell's exiting and overwriting the history at the same time another shell is starting. Admittedly, I didn't look into that...
Doing a little testing, I guess multiple readers from a named pipe is not a good idea. :) You could still do the one-pipe-per-shell thing with the environment variable, though. Wait, that'd be awful. If you do that, don't let anyone know that I suggested it. I need to wash my keyboard after such a suggestion.
I haven't gotten to it, yet, but I'm pretty sure that a little scripting and the "trap 0" capability will be enough to give me what I want. I'll report back when I get some concrete results.
--Danny
Randall Schulz
participants (4)
-
Danny Sauer -
Leendert Meyer -
peter Nikolic -
Randall R Schulz