Re: [bash-bug] no local bash_history created or written to if existing (~/.bash_history

[Chet Ramey]

On 3/8/11 11:51 AM, Dr. Werner Fink wrote:
> On Tue, Mar 08, 2011 at 11:19:25AM -0500, Chet Ramey wrote:
>> On 3/8/11 5:29 AM, Dr. Werner Fink wrote:
>>
>>>> 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.
>>>
>>> That will cause a lot of bugreports.  Just a question: could an atexit()
>>> handler an option or an other way the bash could make use use an extra
>>> (sig)longjmp()/(sig)setjmp() after increasing an atomic control variable
>>> in the signal handlers for SIGHUP/SIGTERM to run all things done short
>>> before exit.
>>
>> The signal handling is already split up between a handler and a function
>> that does the processing when it's `safe'.  The problem is that there are
>> some signals that have to be handled immediately because it's really not
>> possible to continue after receiving them (e.g., SIGSEGV), and some cases
>> where you have to handle the signal immediately because you're not in a
>> position to wait until a safe time (e.g., when reading input from the
>> terminal using read(2)).  This is the latter case.
>>
>> I might be able to finesse this particular case based on the state that
>> readline exports to the calling application.  Another option is to take
>> advantage of the fact that bash installs the SIGHUP handler without the
>> SA_RESTART flag, but that requires more extensive changes.
> 
> Does this mean that the attached patch could also not work
> on some systems? Or does this interfere with the readline
> library?

Since longjmp is not on the list of functions that is safe to call
from a signal handler, yes, that's what it means.  OTOH, this shows
promise as a solution.

> That would be a problem as I'm pretty sure that most users
> will see this a major bug.  Even sysadmins will open a bug
> as a simple shutdown will miss their last few command lines.

I really wish there was a better solution to the close button problem
than SIGHUP.

Chet

-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
                 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, ITS, CWRU    chet@case.edu    http://cnswww.cns.cwru.edu/~chet/