> That's not an unreasonable assumption, but it needs to be verified, and
> nobody has been able to provide solid evidence that bash is at fault.
If one thing is changing and it breaks something, it is very logical to
start the investigation there. I don't say that Bash is the fault,
because it co
On Mon, Mar 07, 2011 at 10:22:55PM -0500, Chet Ramey wrote:
> On 3/6/11 2:53 PM, Doug McMahon wrote:
> > with the current bash used in ubuntu 11.04 there no longer is a
> > ~/.bash_history created
> > If there is an existing ~/.bash_history in place or one is inadvertently
> > created, *see below,
On Tue, Mar 08, 2011 at 11:29:22AM +0100, Werner Fink wrote:
> On Mon, Mar 07, 2011 at 10:22:55PM -0500, Chet Ramey 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 fun
On 03/08/2011 12:32 PM, Dr. Werner Fink wrote:
Something like the attached patch.
Seems it doesn't work. I have applied your patch, run that bash in
gnome-terminal, close the terminal. In gdb I set a break to atexit() and
maybe_save_shell_history() functions. Bash receives SIGHUP, I say
conti
On Tue, Mar 08, 2011 at 03:07:13PM +0100, Roman Rakus wrote:
> On 03/08/2011 12:32 PM, Dr. Werner Fink wrote:
> >Something like the attached patch.
> >
> Seems it doesn't work. I have applied your patch, run that bash in
> gnome-terminal, close the terminal. In gdb I set a break to atexit()
> and m
Running "strace -f vzctl enter 152 " shows:
[pid 19449] rt_sigaction(SIGTSTP, {0x80e0b10, [], SA_RESTORER,
0x9f8e98}, {0x1, [], SA_RESTORER, 0x9f8e98}, 8) = 0
[pid 19449] rt_sigaction(SIGTSTP, {0x1, [], SA_RESTORER, 0x9f8e98},
{0x80e0b10, [], SA_RESTORER, 0x9f8e98}, 8) = 0
[pid 19449] rt_sigaction
On 3/8/11 10:10 AM, Dr. Werner Fink wrote:
> On Tue, Mar 08, 2011 at 03:07:13PM +0100, Roman Rakus wrote:
>> On 03/08/2011 12:32 PM, Dr. Werner Fink wrote:
>>> Something like the attached patch.
>>>
>> Seems it doesn't work. I have applied your patch, run that bash in
>> gnome-terminal, close the t
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
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 execu
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, sin
On 03/08/2011 06:02 PM, Chet Ramey wrote:
I really wish there was a better solution to the close button problem
than SIGHUP.
+1, or learn people to exit from shell.
RR
On Tue, Mar 08, 2011 at 12:02:53PM -0500, Chet Ramey wrote:
> >
> > 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,
(03/08/2011 09:19 AM), Roman Rakus wrote:
> On 03/08/2011 06:02 PM, Chet Ramey wrote:
>> I really wish there was a better solution to the close button problem
>> than SIGHUP.
> +1, or learn people to exit from shell.
Yeah, but what of when your ssh connection goes down (and you're not
using screen
"Dr. Werner Fink" writes:
> On Tue, Mar 08, 2011 at 12:02:53PM -0500, Chet Ramey wrote:
>> >
>> > 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 s
On 03/08/2011 11:00 AM, Andreas Schwab wrote:
> "Dr. Werner Fink" writes:
>
>> On Tue, Mar 08, 2011 at 12:02:53PM -0500, Chet Ramey wrote:
Does this mean that the attached patch could also not work
on some systems? Or does this interfere with the readline
library?
>>>
>>> Sinc
On 3/8/11 1:32 PM, Eric Blake wrote:
> Really, the only safe way to handle things like SIGHUP cleanup is to
> have the signal handler record that an exception occurred, then have the
> main processing loop checking that variable frequently enough to do
> cleanup in a reasonable time-frame (possibl
On 3/8/11 10:04 AM, gnu.bash.bug wrote:
> Running "strace -f vzctl enter 152 " shows:
So vzctl is running bash in a pty and talking to it that way?
I'd be interested in seeing what interrupted the select/read/write/
sigprocmask system calls in both processes.
Chet
--
``The lyf so short, the cr
On 3/8/11 11:12 AM, Chet Ramey wrote:
> I might be able to finesse this particular case based on the state that
> readline exports to the calling application.
I think I was able to do that. Try the attached patch; it works for me.
It identifies a single specific common case and allows the hist
Looks like you've got it all wrong.
ulimit -m operates in units of 1024 pages each:
Yes. But one page can be more than 1024. In my case - 4096. If I set
ulimit -m 1024, one user can get RSS (in top) 1500 kBytes. I hit this
when my server was drown in swapping, when users ulimits were set to
19 matches
Mail list logo
