bash 4.2 does not save history (~/.bash_history) when using close window

Bug #725327 reported by Doug McMahon
136
This bug affects 26 people
Affects Status Importance Assigned to Milestone
bash (Ubuntu)
Fix Released
Undecided
Unassigned

Bug Description

Binary package hint: bash

The latest upgrade to bash 4.2-0ubuntu1 has caused no more entries to be written to ~/.bash_history
Reverting to 4.1-2ubuntu5 allows entries to be added again as expected

ProblemType: Bug
DistroRelease: Ubuntu 11.04
Package: bash 4.2-0ubuntu1
ProcVersionSignature: Ubuntu 2.6.38-5.32-generic 2.6.38-rc6
Uname: Linux 2.6.38-5-generic i686
Architecture: i386
Date: Fri Feb 25 17:52:30 2011
InstallationMedia: Ubuntu 11.04 "Natty Narwhal" - Alpha i386 (20110202)
ProcEnviron:
 LANGUAGE=en_US:en
 PATH=(custom, user)
 LANG=en_US.UTF-8
 SHELL=/bin/bash
SourcePackage: bash

Revision history for this message
Doug McMahon (mc3man) wrote :
Revision history for this message
Doug McMahon (mc3man) wrote :

If the current ~/.bash_history is removed a new one will not be created

tags: added: regression
removed: running-unity
Revision history for this message
Doug McMahon (mc3man) wrote :

Final on this for me -

Fresh A3 install -
open a terminal, run some commands, commands are retrievable in the open terminal
close terminal - no ~/.bash_history is created
open a new terminal - no commands can be retrieved.

One way a bash_history can be created and a command saved ((crash compiz with a command running in a terminal -

Same fresh A3 install
Login to unity desktop, install ccsm
Open a terminal and start ccsm thru it
Pick any method to crash compiz - disabling and then re-enabling the unity plugin should do.
After compiz crashes do a logout/in (keyboard shortcut is a good way
Look in home dir. - a bash_history should be there with 1 command , - "ccsm"

Open a terminal, run a command, close - it will not be added to the new ~/.bash_history

Revision history for this message
wobblybob (martincooper9) wrote :

Using Natty Alpha 3 Xubuntu Terminal no longer adds items to the bash_history and after deleting the old history the terminal does not recreate it. The Terminal itself only remembers the last command used whilst left open and forgets that when it is restarted.

tags: added: iso testing
Revision history for this message
miegiel (nix-miegiel) wrote :

'bash 4.2-0ubuntu2' has the bug too. But it wouldn't surprise me if the bug is in 'xfce4-terminal' (current version: 0.4.6-1ubuntu1) and not in 'bash'. I can't remember a 'bash' update passing by recently and I'm sure 'xfce4-terminal' did update in the past days, though it's impossible to remember every update.

Revision history for this message
Doug McMahon (mc3man) wrote :

I'm going to leave this open for those that are wondering what's changed and how to get a ~/.bash_history created and written to

With bash 4.2 you need to use an exit command when closing a terminal, if you do so it will then write to your history

As relayed by chet ramey -
> One thing that has changed is that an interactive shell will no longer
> attempt to write the history file if it's killed by a signal, since that
> causes many functions to be executed that are not safe to call from a
> signal handler. If you're in the habit of trying to exit the shell by
> closing the terminal window, which causes the shell to be killed by SIGHUP
> (I think, maybe SIGTERM), the history will not be saved.
>
> Chet

vmc (vmclark)
Changed in bash (Ubuntu):
status: New → Confirmed
Doug McMahon (mc3man)
summary: - bash 4.2 does not save history (~/.bash_history
+ bash 4.2 does not save history (~/.bash_history) when using close window
Revision history for this message
Doug McMahon (mc3man) wrote :

I'm actually fine with this new behavior now that I know the why and how to get the history written to (exit command; Ctrl+d
Certainly it's not my place to mark as 'will not fix', though I think someone in that position should either do so or comment as seen fit.
It wouldn't hurt to have noted this change in the bash changelog or to do so appropriately in the future if no change to this behavior is made

Revision history for this message
John Doe (jodo-deactivatedaccount) wrote :

I'm not fine with this nor do I think most people will. This is an unexpected behaviour and many people will be confused about this.

Revision history for this message
Justin (deadite81) wrote :

I agree. It was a few days before figured out how to get it working again. First I found this bug report, but after following the instructions it still wouldn't work. Turns out it was a setting in my extensively modified bashrc relating to history. Drove me nuts. Now I still close the window with the window controls, like Every_Other_Window and lose my history. This is very inconsistent behavior. I have been using Linux for close to 2 years now...why is it all of a sudden "dangerous" to save the history by exiting the ui properly?

Revision history for this message
John Doe (jodo-deactivatedaccount) wrote :

Until another and better solution is there, I worked this around by installing bash 4.1 from Maverick.

Revision history for this message
Doug McMahon (mc3man) wrote :

I'm not going to speak for the ubuntu/debian maintainer(s) who have remained silent on this , but a few add. comments

The change concerning this was made upstream, I'd certainly consider their/his (chet ramey) knowledge of bash to be such that the change was well justified. (nothing I could remotely question

Ubuntu tends not to change upstream code unless there is some really good reason, - don't see that here.
While I also had gotten in the habit of closing the terminal window, it's really no big deal, when wishing the command(s) used in the current term to be saved, to just use Ctrl+d

Actually see this as a positive - if I want the command(s) saved I use Ctrl+d, if I don't then I just close the window.
Also keeping in mind this in no way affects using the history - you're free to copy one over and or edit commands in the current one
My only complaint here was that this should have been noted in the changelog - certainly considering that history has always been saved no matter how the term was closed in the past.

Revision history for this message
John Doe (jodo-deactivatedaccount) wrote :

No single good point for me. Tell me, please, only ONE good reason to change the behaviour we have until this, not really good, pronounced change.

I cannot image any point.

You will get a lot of bugreports for this. And, sorry, but do you overtake any change from upstream, without thinking about it?

Revision history for this message
Justin (deadite81) wrote :

All points here are well taken, and I will of course get used to the new behavior.

That doesn't change the fact that that this was a large disruption to my every day usage. I realize I'm just complaining now, but it seems there should be a mechanism in place to inform users of substantial under the hood changes like this that are very likely to confuse average users such as myself. Yes, there is the ability to view changelogs, but those are easy to pass over for standard updates. Besides, if I looked at every change log, many of which I can't understand anyway, that's all I'd do.

Revision history for this message
Doug McMahon (mc3man) wrote :

Justin wrote > but it seems there should be a mechanism in place to inform users ....
there is in the release notes, not sure this 'qualifies'

Revision history for this message
Justin (deadite81) wrote :

Doug McMahon wrote > there is in the release notes, not sure this 'qualifies'

I suppose that's the same as "changelog"? As in what you get when using the Update Manager? That functionality is of course already present, but I was thinking more along the lines of a mechanism that makes it easy for an application to issue a one time popup or notification of some sort to alert the user about a change that they otherwise would be totally unaware of, such as this "bug". Perhaps it's not a bug because it is intended functionality (and realistically not a big deal), but it becomes a issue when it can be logically assumed that people will not understand the change naturally, especially with such a widely used application as Bash. This is a core program used by many people every single day and although the change is easily understood, it's not if the user doesn't know about it.

This "bug" seems to fall into a gray area: according to the maintainer it is a necessary enhancement; to the average user it is a bug because it *appears* that well established functionality has been removed.

Average users cannot be expected to read every changelog. Ideally they would, but if mainstream user are to be attracted by Linux and Ubuntu in particular it's just not going to happen unless the information is directly presented to them in a friendly way. I understand the Update Manager provides this functionality to some extent (KDE's does it much better), but there's plenty of cases it's simply not feasible, like during a disrto upgrade. Would it not be awesome if, for example, Bash's latest *important* changes were presented in terminal the first time it was started after an update? Maybe not to some people, but at least they would have been aware of this crucial change in functionality. This particular instance of update should be "forced" knowledge, even if the delivery method (a gtk popup, a web page, etc.) is considered intrusive or annoying. I realize this methodology could be thoroughly abused (Windows is a glaring example), but....

I'm probably beating a dead horse here, but the point is this: I'm a relatively experienced user who is interested in development and release notes and so on and I ended up with this problem. Take that as you will (laziness/unperceptive behavior on my part, or whatever), but it still happened to me and caused confusion and disruption to my computer usage. This is not in line with Ubuntu's stated philosophy of being easy for everyone (because, as I said before, Bash is a core application and very important).

Revision history for this message
John Doe (jodo-deactivatedaccount) wrote :

Thanks for the good explaination. Your Idea with the *notification* is really nice. I know this is not the right place for discussions, but anyway, there are two points that are important for me:

For me, personal, it is a bug. It doesn't "appear" that a function has been removed. It HAS been removed. A function that was there before and is away now is a regression. And we have the first users in our forums that are confused about this.

But I totally agree with your last statement.

Beside of this: is this only happening with bash, or can I, as a User that don't likes this behaviour, choose another system-wide shell?

Revision history for this message
Justin (deadite81) wrote :

I think it could be interpreted both ways - regression or feature. I personally think it's a regression and should be patched, but I guess we'll just have to wait and see.

As for another shell, "zsh" is similar to bash and is available in the repos. It has the old history behavior. I'd also recommend checking out ohmyzsh on github. You'll need to Google it, as setting it up as default takes some configuring and this isn't the place for a tutorial.

Revision history for this message
Sam Rog (samrog131) wrote :

Installed shells (/etc/shells: valid login shells): cat /etc/shells

Change login shell: chsh

Example:

Installing zsh ("a shell with lots of features"): sudo apt-get install zsh

Valid shells: cat /etc/shells
=>
...
/bin/zsh
/usr/bin/zsh
...

Changing: chsh -s /bin/zsh

Log out & Log in

The terminal (konsole at here) is starting with the history, defaults are( .zshrc):
# Keep 1000 lines of history within the shell and save it to ~/.zsh_history:
HISTSIZE=1000
SAVEHIST=1000
HISTFILE=~/.zsh_history

Revision history for this message
Doug McMahon (mc3man) wrote :

Justin wrote > I suppose that's the same as "changelog"?
No, the release notes are available when installing in the installer and at/after release from the ubuntu site where 'get ubuntu' is shown.

anyway there seems to be many options here available from the user side, what the official end result will be I don't know - odds are it will stay as is.

Seeing as you guys are interested in 'changes from historical behavior', you may wish to glance here - a similar no response except from user base bug.
Bug #692391

Revision history for this message
Justin (deadite81) wrote :

Doug McMahon wrote > No, the release notes are available when installing in the installer and at/after release from the ubuntu site where 'get ubuntu' is shown.

Oh. I didn't think things like this were included in the release notes.

Thanks for linking to your sudo bug, that's actually very helpful! I thought it was just some bug in Natty that was soon to be addressed.

It's nice to know that obscure but fundamental changes are being made behind the scenes like this... Don't remember using the Karmic/Lucid/Maverick pre-releases being this rough (except for the apparently perennial hatred between xorg and Nvidia, of course). I guess the best thing I can do is pay more attention :) http://www.ubuntuupdates.org is my new best friend, I guess.

Revision history for this message
Ngassam Nkwenga (cyrildz) wrote :

I'm not always opposed to Change but this one is really a bug. what if the computer just get unplugged and shutdown ? they are many options I don't totally remember , so the history is a good help for this.

Revision history for this message
wobblybob (martincooper9) wrote :

<QUOTE>I'm probably beating a dead horse here, but the point is this: I'm a relatively experienced user who is interested in development and release notes and so on and I ended up with this problem. Take that as you will (laziness/unperceptive behavior on my part, or whatever), but it still happened to me and caused confusion and disruption to my computer usage. This is not in line with Ubuntu's stated philosophy of being easy for everyone (because, as I said before, Bash is a core application and very important).</QUOTE>

agree with this I use the history option all the time as I have old timer disease :-) and now the behavior of one of the simplest tools available to the linux user has been changed for what seems like a no good reason to me. I'm all for change but not change just for the sake of it.

Revision history for this message
Doug McMahon (mc3man) wrote :

While it would be nice if someone whose 'opinion' does matter (in terms of debian/ubuntu) commented on this, one might take the lack of in a couple of ways
There is a huge triaging/bug fixing going on and this may be of very low importance, interest, or -
it is the way it is now. (nothing to be said or done.

I've gotten used to it (for the most part) and as mentioned find it a handy way to include or exclude commands being written

Revision history for this message
Doug McMahon (mc3man) wrote :

And I think it is worth repeating -
If the current bash maintainer, chet ramey, feels this is the correct behavior , then I'm not in a position to question and I've seen no one post any 'evidence' to contrary
(his comments are in post 6

Revision history for this message
Mike (bild85) wrote :

Gimmie the stick...I'd like to take a few swings at that dead horse too. It would have been nice to get a message when I opened terminal for the first time that explained this loss of function. I rely heavily on .history and lost another 30 minutes tracing down this bug report.

Revision history for this message
linuxar (linuxar) wrote :

Hi all,

Pls see

https://bugs.launchpad.net/ubuntu/+source/gnome-terminal/+bug/740346?comments=all

for a closely-related bug, now in the GUI shell (i.e. "gnome-terminal") and my suggestion at:

https://bugs.launchpad.net/ubuntu/+source/gnome-terminal/+bug/740346/comments/5

Revision history for this message
Justin (deadite81) wrote :

Those are both good suggestions, at least some kind of visual indicator (i.e., menu entry) would be good for people not aware of this change. Thing is, if someone patches GNOME Terminal to fix this, it will still affect xterm, Konsole, Guake, and all the other front-ends out there.

I'm still loosing lots of valuable history from forgetting to press ctrl+D...I guess I'll get used to it eventually. It seems no matter how pissed I get about losing my long commands I still close the window by traditional methods because I've been, apparently erroneously, led to believe that's how I'm supposed to close windows. All windows EXCEPT one I guess. Hopefully soon they'll implement a feature that requires me to press ctrl+H to save my web history when I close Firefox and ctrl+L for my Pidgin logs.

Revision history for this message
Sam Rog (samrog131) wrote :

For those who want to compare the shells > http://www.faqs.org/faqs/unix-faq/shell/shell-differences/.

A quote:

"Why change your shell

   The UNIX shell is most people's main access to the UNIX operating
   system and as such any improvement to it can result in considerably
   more effective use of the system, and may even allow you to do things
   you couldn't do before. The primary improvement most of the new
   generation shells give you is increased speed. They require fewer key
   strokes to get the same results due to their completion features, they
   give you more information (e.g. showing your directory in your prompt,
   showing which files it would complete) and they cover some of the more
   annoying features of UNIX, such as not going back up symbolic links to
   directories."

By the "UNIX shell differences and how to change your shell" the csh, ksh, tcsh and the zsh have the command history. (It is still telling that the bash has the command history )

Revision history for this message
Mingming Ren (portis25) wrote :

Recent update of bash (4.2-0ubuntu3) integrates a upstream patch for this bug.

 # DP: bash-4.2 upstream patch 008

                             BASH PATCH REPORT
                             =================

Bash-Release: 4.2
Patch-ID: bash42-008

Bug-Reported-by: Doug McMahon <email address hidden>
Bug-Reference-ID: <1299441211.2535.11.camel@doug-XPS-M1330>
Bug-Reference-URL: http://lists.gnu.org/archive/html/bug-bash/2011-03/msg00050.html

Bug-Description:

Bash-4.2 does not attempt to save the shell history on receipt of a
terminating signal that is handled synchronously. Unfortunately, the
`close' button on most X11 terminal emulators sends SIGHUP, which
kills the shell.

This is a very small patch to save the history in the case that an
interactive shell receives a SIGHUP or SIGTERM while in readline and
reading a command.

The next version of bash will do this differently.

Revision history for this message
Doug McMahon (mc3man) wrote :

Well then this can be marked as fix released
(gotta love how gnu.org posts my email in full....

Revision history for this message
Justin (deadite81) wrote :

Just for reference, here's the changelog from Ubuntu's update manager:

Changes for the versions:
4.2-0ubuntu2
4.2-0ubuntu3

Version 4.2-0ubuntu3:

  * Apply upstream patches 007 - 008.

So even when I don't overlook the...you get the point. It's nice that it's fixed though :)

Doug McMahon (mc3man)
Changed in bash (Ubuntu):
status: Confirmed → Fix Released
Revision history for this message
James M. Leddy (jm-leddy) wrote :

I think this has regressed again in precise. At least when I issue shutdown I lose all my histories.

Revision history for this message
Doug McMahon (mc3man) wrote : Re: [Bug 725327] Re: bash 4.2 does not save history (~/.bash_history) when using close window

On 08/03/2012 10:51 AM, James M. Leddy wrote:
> I think this has regressed again in precise. At least when I issue
> shutdown I lose all my histories.
>
Well maybe that's from "shutdown" not bash?
At least here since the change in bash was reverted history is always
saved except if log out/restart/shutdown is done from indicator,
(indicator-session/gtk-logout-helper) while the terminal is still open

If shutting down from the terminal then history is saved

Revision history for this message
Antonio J. de Oliveira (ajoliveira) wrote :

In Xubuntu Saucy 64-bit I had the same problem, somehow during installation .bash_history was owned by root. Just had it modified by:

sudo chown <user>.<user> .bash_history

and

sudo chmod 755 .bash_history

and got my history back

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Other bug subscribers