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
Thanks Chet.
Couple of notes:
1) I’m not setting HISTFILESIZE, only HISTSIZE. HISTFILESIZE is getting set for
me based on my choice of HISTSIZE (though I assume this is something that bash
does that you know about).
2) As mentioned in the initial bug report, if I set PROMPT_COMMAND='history -
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
On 11/4/14 5:16 PM, Piotr Grzybowski wrote:
> 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):
There is an iss
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 native way? I know that zsh has the setopt
shar
> On 6 Nov 2014, at 9:11 am, Piotr Grzybowski wrote:
>
> On Wed, Nov 5, 2014 at 2:57 PM, Chet Ramey wrote:
>> I still can't reproduce it on OS X 10.10: [..]
>
> not only I cannot reproduce it at the moment, but also I have reached
> the following state (user: root):
>
> # cat .bash_history
>
On Wed, Nov 5, 2014 at 2:57 PM, Chet Ramey wrote:
> I still can't reproduce it on OS X 10.10: [..]
not only I cannot reproduce it at the moment, but also I have reached
the following state (user: root):
# cat .bash_history
ls -al
#1415144153
ls -al .bash_history
#1415144154
pwd
#1415144159
rm .
On 11/4/14, 5:16 PM, Piotr Grzybowski wrote:
> 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
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
On Tue, Nov 4, 2014 at 10:44 PM, Graham Jones
wrote:
> Now I was expecting a hole in the file, but when I finally get to see the
> contents, I have 500,000 ls commands in there (one of my test commands from
> above)
just for the record, now I have $HISTSIZE
i=0; while [ $i -lt 25 ]; do histor
> 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
Hi Graham,
On Tue, Nov 4, 2014 at 10:19 PM, Graham Jones
wrote:
> Really? Very interesting.
> I assume that it’s not reproducible with the version of bash that ships with
> 10.6.8 however?
not exactly the version shipped with 10.6.8, more like installed by hand:
# which bash
/opt/local/bin//ba
> 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 permanently hangs.
I wasn't a
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 how quickly
27 matches
Mail list logo
