gt;> you wait until you have more than $HISTSIZE history entries, you'll lose
>>> information no matter what you use.
>>
>> I don't think that happens frequent either. But it's possible. Someone set
>> HISTSIZE to 1000 as he don't care about too old com
sible. Someone set
> HISTSIZE to 1000 as he don't care about too old commands and it's happened
> that he typed more than 1000 command. Then he run "history -a" to synchronize
> current history with another started bash for example. And lost recent
> commands. P
pened that
he typed more than 1000 command. Then he run "history -a" to synchronize
current history with another started bash for example. And lost recent
commands. Possibly he notice it. But may not.
Anyway I don't see downsides of this behavior comparing to current. And it
t new session. And it's
> happened that we type more than $HISTSIZE commands. Then if I type "history
> -a", I expect that $HISTSIZE commands will be appended to history file
> (leading commands will disappear, as our buffer can't hold this much
> commands).
istory -c
>> $ HISTSIZE=2
>> $ HISTFILE=$(mktemp)
>> $ history -a
>> $ cat $HISTFILE
>> $
>> File is still empty!
>> bashhist.c:maybe_append_history():
>> if (history_lines_this_session > 0 && (history_lines_this_session <=
>> where_history
On 2/10/19 4:59 PM, Айрат Васбикарамов wrote:
> Machine Type: x86_64-unknown-linux-gnu
> Bash Version: 4.4
> Patch Level: 23
> Release Status: release
> Description:
> $ history -c
> $ HISTSIZE=2
> $ HISTFILE=$(mktemp)
> $ history -a
> $ cat $HIST
:22 UTC 2018 x86_64 GNU/Linux
Machine Type: x86_64-unknown-linux-gnu
Bash Version: 4.4
Patch Level: 23
Release Status: release
Description:
$ history -c
$ HISTSIZE=2
$ HISTFILE=$(mktemp)
$ history -a
$ cat $HISTFILE
$
File is still empty!
bashhist.c:maybe_append_history():
if (history_lines_this_se
On 6/9/15 7:42 PM, Reuben Thomas wrote:
> At least in bash 4.3, the documentation for history -a says:
>
> Append the new history lines (history lines entered since the
> beginning of the current Bash session) to the history file.
>
> This is unfortunately
At least in bash 4.3, the documentation for history -a says:
Append the new history lines (history lines entered since the
beginning of the current Bash session) to the history file.
This is unfortunately misleading, since it suggests that the technique of
adding "histo
Good point Graham, definitely good place to start.
If you are interested we can discuss further, privately. Mainly
because I want to say some nasty things about implementing sharing and
locking resources withouth ipc. :))
cheers,
pg
On Fri, Nov 7, 2014 at 1:38 PM, Graham Jones
wrote:
> Guys
Guys thanks so much for taking this discussion further than just the reported
bug that prevented the existing workaround.
I’ve often considered putting this work in myself but wasn’t sure what the
reason was for this not being in bash already and if there was an architectural
difficulty with im
On Fri, Nov 7, 2014 at 1:26 PM, Eric Blake wrote:
>
> Named pipes (aka fifos) are notorious for being buggy on Cygwin and
> non-available on mingw.
thanks Eric. good news.
so this means, that shared history can only be implemented using
regular files. is that right?
cheers,
pg
On 11/07/2014 12:23 PM, Piotr Grzybowski wrote:
> On Thu, Nov 6, 2014 at 3:15 PM, Chet Ramey wrote:
>>
>> There is no "standard ipc" except pipes across the range of systems bash
>> runs on.
>
> thanks. good to know, before I open the flood gate of git commits ;-)
> can I assume that this inclu
On Thu, Nov 6, 2014 at 3:15 PM, Chet Ramey wrote:
>
> There is no "standard ipc" except pipes across the range of systems bash
> runs on.
thanks. good to know, before I open the flood gate of git commits ;-)
can I assume that this includes named pipes?
cheers,
pg
On 11/6/14, 5:19 AM, Piotr Grzybowski wrote:
> On Thu, Nov 6, 2014 at 3:28 AM, Chet Ramey wrote:
>>
>> In theory, one could change the functions in history.c and histfile.c to
>> change the in-memory history list to one that uses a file, possibly with
>> mmap().
>> I'd be happy to look at contribu
On Thu, Nov 06, 2014 at 11:19:55AM +0100, Piotr Grzybowski wrote:
> would you accept a solution like this:
>
> 1. all running instances of bash with history support on, share
> history via shmem segment (some care as to its size should be taken)
> ...
As long as it is off by default. This is th
On Thu, Nov 6, 2014 at 3:28 AM, Chet Ramey wrote:
>
> In theory, one could change the functions in history.c and histfile.c to
> change the in-memory history list to one that uses a file, possibly with
> mmap().
> I'd be happy to look at contributed code to do this [..]
would you accept a soluti
On Nov 6, 2014 3:25 AM, "Chet Ramey" wrote:
>
> On 11/4/14 5:16 PM, Piotr Grzybowski wrote:
> > Chet: for reasons unexplained calls to read_history_range at [..]
>
> There is an issue with this particular, relatively infrequent, set of
> circumstances [..]
>
Thanks a lot Chet, seems that this wa
this particular, relatively infrequent, set of
> circumstances:
>
> 1. HISTFILESIZE > HISTSIZE
> 2. Actual size of the history file > HISTSIZE
> 3. history list contains HISTSIZE entries
> 4. the user executes a sequence of `history -a; history -n'. Even
> `histo
On 11/5/14 8:39 PM, Graham Jones wrote:
> Just out of curiosity, this mechanism is obviously something of a work
> around to give bash a single shared history in the same style as ksh had.
> Has there ever been any thought of providing a mechanism to support a
> single history session in a more na
LESIZE):
There is an issue with this particular, relatively infrequent, set of
circumstances:
1. HISTFILESIZE > HISTSIZE
2. Actual size of the history file > HISTSIZE
3. history list contains HISTSIZE entries
4. the user executes a sequence of `history -a; history -n'. Even
`histor
story
> #1415144154
> pwd
> #1415144159
> rm .bash_history
> #1415144161
> cd
> #1415144163
> pwd
> #1415144165
> rm .bash_history
> #1415144171
> i=0; while [ $i -lt 64 ]; do history -a; history -n; let i++; done;
>
> # ls -alh .bash_history
> -rw--
ot):
>
> # cat .bash_history
> ls -al
> #1415144153
> ls -al .bash_history
> #1415144154
> pwd
> #1415144159
> rm .bash_history
> #1415144161
> cd
> #1415144163
> pwd
> #1415144165
> rm .bash_history
> #1415144171
> i=0; while [ $i -lt 64 ]; do his
44159
rm .bash_history
#1415144161
cd
#1415144163
pwd
#1415144165
rm .bash_history
#1415144171
i=0; while [ $i -lt 64 ]; do history -a; history -n; let i++; done;
# ls -alh .bash_history
-rw--- 1 root wheel 9.0M Nov 5 22:59 .bash_history
# du -sh .bash_history
9.0M.bash_history
# he
./bash --rcfile bashrc
(2)$ echo $BASH_VERSION
4.3.30(22)-release
(2)$ ls -l $HISTFILE
-rw--- 1 chet staff 402 Nov 5 08:49 history-file
(2)$ wc -l < $HISTFILE
20
(2)$ echo $HISTSIZE $HISTFILESIZE
500000 500000
(2)$ for (( i = 0; i < 30 ; i++ )); do history -a ; history -n ; done
(
Chet: for reasons unexplained calls to read_history_range at
history.def:219
219 result = read_history_range (filename, history_lines_in_file, -1);
return more and more records (77824 is above my HISTFILESIZE):
1: history_lines_in_file = 77824
the loop at histfile.c:269 in read_histo
25 ]; do history -a; history -n; let i++; done;
commands in .bash_history :)
cheers,
pg
P.S.
pity I really needed those ;-)
> On 5 Nov 2014, at 12:54 am, Chet Ramey wrote:
>
> On 11/3/14 5:08 PM, Graham Jones wrote:
>> These are for:
>> bash --version
>> GNU bash, version 4.3.30(1)-release (x86_64-apple-darwin14.0.0)
>
> This trace looks pretty reasonable. Maybe you could temporarily move your
> history file to som
reproduce it (and I’m
> not sure that just hitting enter even puts anything in the history).
well, thats strange, but it means that this also should do the trick,
without setting PROMPT_COMMAND:
# i=0; while [ $i -lt 25 ]; do history -a; history -n; let i++; done;
it actually does for me,
> On 5 Nov 2014, at 4:49 am, Piotr Grzybowski wrote:
>
> Hi,
>
> reproducible on mac os x 10.6.8
Really? Very interesting.
I assume that it’s not reproducible with the version of bash that ships with
10.6.8 however?
> This is free software; you are free to change and redistribute it.
> There
Hi,
reproducible on mac os x 10.6.8
# uname -a
Darwin 10.8.0 Darwin Kernel Version 10.8.0: Tue Jun 7 16:33:36
PDT 2011; root:xnu-1504.15.3~1/RELEASE_I386 i386
# bash --version
GNU bash, version 4.3.24(1)-release (x86_64-apple-darwin10.8.0)
Copyright (C) 2013 Free Software Foundation, Inc.
L
On 11/3/14 5:08 PM, Graham Jones wrote:
> These are for:
> bash --version
> GNU bash, version 4.3.30(1)-release (x86_64-apple-darwin14.0.0)
This trace looks pretty reasonable. Maybe you could temporarily move your
history file to some other name and see if you can reproduce this behavior
starting
Resend with missing stats for truss after ctrl-C
> On 4 Nov 2014, at 9:08 am, Graham Jones
> wrote:
>
> These are for:
> bash --version
> GNU bash, version 4.3.30(1)-release (x86_64-apple-darwin14.0.0)
>
> lldb backtrace:
> (lldb) process attach --pid 5955
> Process 5955 stopped
> Executable mo
These are for:
bash --version
GNU bash, version 4.3.30(1)-release (x86_64-apple-darwin14.0.0)
lldb backtrace:
(lldb) process attach --pid 5955
Process 5955 stopped
Executable module set to "/usr/local/bin/bash".
Architecture set to: x86_64h-apple-macosx.
(lldb) bt
* thread #1: tid = 0x169339, 0x00
On 10/29/14, 1:31 AM, Graham Jones wrote:
> Since upgrading to OS X 10.10 Yosemite and thus bash 3.2.53 use of the
> PROMPT_COMMAND='history -a; history -n'
> workaround to get a single ksh-style history causes the shell to become less
> and less responsive until it perman
Since upgrading to OS X 10.10 Yosemite and thus bash 3.2.53 use of the
PROMPT_COMMAND='history -a; history -n'
workaround to get a single ksh-style history causes the shell to become less
and less responsive until it permanently hangs.
The problem is somewhat intermitant in terms of h
Thanks, Chet. I'll try the patch out as soon as I can get to it.
Meanwhile, I've also tried to add in some of the examples/loadables
(beyond the "tty" one), and it makes bash unstable. I will also try
to put together a patch that will run through the examples directory
on "make check". I am pret
On 8/9/10 2:07 PM, Bruce Korb wrote:
> My history file isn't being updated as I am led to believe it ought to be.
> Is there some shopt or other thingey that keeps the history unwritten?
> I've googled the issue and the answer is supposed to be "history -a",
> on
My history file isn't being updated as I am led to believe it ought to be.
Is there some shopt or other thingey that keeps the history unwritten?
I've googled the issue and the answer is supposed to be "history -a",
on occasion, but that isn't working:
$ ls -l $HISTFILE
39 matches
Mail list logo
