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 -a; history -r’ in my profile, my terminal was immediately hanging on initialisation. Since reseting the history file though, this no longer seems to be the case. > On 6 Nov 2014, at 1:25 pm, Chet Ramey <chet.ra...@case.edu> wrote: > > 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 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 > `history -a; history -r' would probably prevent this, at the cost > of more malloc/free operations. > > In this case, history_lines_in_file (which, despite its name, is supposed > to keep track of how many lines bash has read from the history file) is > calculated incorrectly. The result is that bash reads way too many lines > from the history file each time. > > There are a couple of ways to fix it: one that uses facilities the history > library provides today and one that changes the history library to expose > the values more directly. One will appear in the next snapshot. > > Chet > > -- > ``The lyf so short, the craft so long to lerne.'' - Chaucer > ``Ars longa, vita brevis'' - Hippocrates > Chet Ramey, ITS, CWRU c...@case.edu http://cnswww.cns.cwru.edu/~chet/