On 7/27/13 12:41 AM, Geoff Kuenning wrote:
> (Does
> bash re-enable signals when the handler gets called? Seems unlikely,
> but...)
No.
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, ITS, CWRUc...@case.ed
> If you are using whatver `close' button your window manager provides to
> exit the shell rather than exit or ^D, it's possible that there is a signal
> race condition involved here. Many window managers send SIGHUP/SIGKILL to
> running processes on window close.
That's pretty much what happens.
On 7/24/13 2:53 AM, Geoff Kuenning wrote:
> I have to confess that I'm equally confused. The probability of a
> malloc failure seems vanishingly small; my bashes are only about 20M
> virtual, my history size is a measly 500, and my current history is just
> over 8K..
>
> I can't think of an inte
Geoff Kuenning wrote:
Instead of "junk", secure file systems mark it as needing to be
zeroed. Perhaps instead of zeroing it ext3 simply marks it of zero
length? Imagine, embedded in the junk are credit cards and passwords
and you'll begin to understand why zero pages are kept "in-stoc
> Instead of "junk", secure file systems mark it as needing to be
> zeroed. Perhaps instead of zeroing it ext3 simply marks it of zero
> length? Imagine, embedded in the junk are credit cards and passwords
> and you'll begin to understand why zero pages are kept "in-stock" (in
> memory) in
Geoff Kuenning wrote:
I can also see the possibility of some kernel or file system routine
waiting after you issue the close call so that it doesn't have to zero
the area where data is arriving. I.e. it might only zero the file beyond
the valid text AFTER some delay (5 seconds?) OR might wai
> As for the problem...the fact that you using 4.2, would seem
> to make the algorith
> open()
> write(whatever we have as history)
> close(set eof to where we are).
>
> What file system are you are? is it local or networked?
Local, ext3.
> one way for it to be zero is if the last bash exi
Geoff Kuenning wrote:
> Linda:
>
> I actually don't use histappend; I like the fact that history eventually
> disappears.
I'm not one to try to sell something so trivial, but do you really
never have a project that lasts more than 1 login session where repeat
commands would be usefu
Linda:
I actually don't use histappend; I like the fact that history eventually
disappears.
Chet:
I have to confess that I'm equally confused. The probability of a
malloc failure seems vanishingly small; my bashes are only about 20M
virtual, my history size is a measly 500, and my current histo
On 7/19/13 3:40 AM, Geoff Kuenning wrote:
> Now, to clarify: the difficulty isn't that bash overwrites the history
> file. That's the default behavior, and it's to be expected. If a user
> opens three shells (in any fashion) and then successively types "exit"
> in each, it's to be expected that
Geoff Kuenning wrote:
> But right now, if all three of those shells exit simultaneously--for
> whatever reason--there is a significant probability that the history
> file will end up zero-length. That's not theoretical; I've experienced
> it multiple times. And that's a bug, plain and simple.
I have to apologize; it's clear that we're not connecting.
I must also apologize for misunderstanding your (Linda's) role; I DO
appreciate getting suggestions and help from a bash fan regardless of
whether you're personally responsible for the code.
It's perhaps also worth mentioning that the und
Geoff Kuenning wrote:
ge...@cs.hmc.edu wrote:
Locking should be used when truncating and writing the history
file. (Yes, I know it's a pain in a portable program like
bash.)
What might be cooler would be to merge all the history lines
from all shells
> ge...@cs.hmc.edu wrote:
>> Locking should be used when truncating and writing the history
>> file. (Yes, I know it's a pain in a portable program like
>> bash.)
>>
>> Strictly speaking, locking is only half a solution, because
>> the net result will be that the saved his
On Wed, 10 Jul 2013, ge...@cs.hmc.edu wrote:
...
What might be cooler would be to merge all the history lines
from all shells, in timestamp order. But given the current
history file format, that seems...hard.
PROMPT_COMMAND='history -a "$HISTFILE"'
--
Chris F.A. Joh
ge...@cs.hmc.edu wrote:
Locking should be used when truncating and writing the history
file. (Yes, I know it's a pain in a portable program like
bash.)
Strictly speaking, locking is only half a solution, because
the net result will be that the saved his
Configuration Information [Automatically generated, do not change]:
Machine: x86_64
OS: linux-gnu
Compiler: gcc -I/home/abuild/rpmbuild/BUILD/bash-4.2
-L/home/abuild/rpmbuild/BUILD/bash-4.2/../readline-6.2
Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='x86_64'
-DCONF_OSTYPE='linux-gnu' -D
17 matches
Mail list logo
