Take the 2-minute tour ×
Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

I like to keep a lot of history, so I have histappend set in my .bashrc. Most of the time everything works fine, with history built up from many shells appending. However, every once and a while, I'll start a new shell and find that I've lost the entire history - and it often only contains some of the commands from the last shell to exit (i.e. it's not just overwriting instead of appending). Because of this, I'm suspicious it's happening at shell exit, rather than from some other process killing the .bash_history file. Supporting this conclusion, I have history command numbers in my prompt, and I've never seen them jump down.

Anyone ever run into a similar problem? Or even just have suggestions how to track down the problem?

share|improve this question
add comment

4 Answers

No idea why this happens, but maybe you can circumvent the problem by forcing bash to write to its history file each time it displays a prompt:

PROMPT_COMMAND="history -a; history -n"

This will write (-a) and then re-read (-n) the history file each time bash prompts for the next command. Additional benefit: you'll get command X in shell 1 in the history of shell 2.

share|improve this answer
Doesn't work on GNU bash, version 3.00.15(1)-release (i686-redhat-linux-gnu) –  David Mackintosh Aug 11 '09 at 12:39
Can you explain what "doesn't work" means? –  innaM Aug 11 '09 at 13:02
The additional benefit you cite is in many cases a downside. It's not the behavior I'm looking for, as I may be carrying out two completely separate tasks in separate shells, and do not want to intermingle their history. This would also likely not help anything. When the history disappears, it is deleting content of .bash_history - I don't expect it'd matter whether they'd been written at shell exit or by PROMPT_COMMAND. –  Jefromi Aug 11 '09 at 22:09
history -n is flaky. It's more reliable to do history -a; history -c; history -r. To explain this, I'll first note that history -a does the right thing - your .bash_history will contain all your commands that you typed, in the order that you typed them - assuming that you run history -a after every command. The challenge is to keep the shell's idea of history in sync with the .bash_history file. This is easy with -c and -r, the problem is that it could be slow if it's large. -n can break because it incorrectly identifies which lines are new. (I'm running out of space here!) –  Aaron McDaid Dec 1 '12 at 13:10
(... if you use -n) Imagine you execute a command in shell 1: ls. Then in another shell, Shell Two, you execute cd. Now, the history in the .bash_history is correct because of the history -a in your PROMPT_COMMAND - it will contain ls \n cd \n. Next, you return to shell One and type pwd. Shell One thinks that there was only command n the history (ls). Now it thinks there are two commands (ls and pwd) in the history. When you do -n it thinks (I have two commands in my history, and there are two commands in .bash_history, therefore I'm up to date.) –  Aaron McDaid Dec 1 '12 at 13:20
show 3 more comments

Sorry to answer my own question, but none of the other answers really address the problem.

I've finally figured out that this only happens when closing gnome-terminal itself (i.e. file > exit, the 'x' button, alt+F4), and even then generally only when closing several terminals in quick succession. It never happens when using ctrl-D to close the shell, letting the terminal follow.

If I can pin it down well enough, I'll file a gnome-terminal bug report. In the meantime, perhaps this will help some other people who get here from google!

share|improve this answer
add comment

I have seen this happen before but it was a problem with disk errors that were happening in increasing frequency. I would run a scan on the drive. If it turns out the drive is fine, I would check to see if this file is not surpassing an arbitrary shell history limit.

Something that might be able to keep that from happening would be to keep pruning the file back to 80 lines or however many commands you want the history to be.

share|improve this answer
I don't have root access on the machine this is happening on, but I'm fairly confident the drive is ok. My home directory is stored on a server in our lab (plenty of RAID, I believe) and nfs-mounted. What do you mean by "arbitrary shell history limit"? This is all happening well below HISTSIZE and HISTFILESIZE, and though I have both set large, they're well below the int bash stores them as. –  Jefromi Aug 11 '09 at 22:13
I would have to say that David Mackintosh's entry is probably what is happening. –  Axxmasterr Aug 11 '09 at 22:40
I am entirely sure that it is not. I should never end up with only two commands in my history, when the last shell to exit had a couple dozen commands, the history file had several hundred, and HISTSIZE/HISTFILESIZE are set to 10000. –  Jefromi Aug 12 '09 at 0:37
add comment

My experience was that shells updated the history file at exit time. So a shell's initial "history" depended on the most recently exited shell's view of the history.

The result of this is that you can get commands coming and going from the history, depending on how other shells started and stopped.

share|improve this answer
I understand very well how the history file is written - this is why I specified in my question that I'm using histappend. The problem is not unexpected content, but a total loss of previously stored content. –  Jefromi Aug 11 '09 at 22:14
This explains why I was losing my history... –  B Seven Aug 20 '12 at 23:13
add comment

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.