Re: Savannah and (getting old) issue 108530 reported there
On 6/2/15 5:24 AM, Balaco Baco wrote: > I'm surprised to read you saying that this is not a problem with Bash. Because technically the history facilities are provided by readline, and bash builds on those. > I use Bash as my shell. As configure it (from its appropriate config > file). And I get results opposite to what would be expected. And you say > there is no problem with bash? Bash does not only deal with in memory > lists because it reads the history from the file .bash_history when we > open a new session. It will read history files with duplicate commands > it wrote before, although we configured for not doing this. It reads and writes history files, but the session history it keeps, and the history that, for instance, the `history' and `fc' commands act on, is a list kept in memory and managed by the history library that's part of readline. This is the way it has always been. You may not like that design. You may think it causes you problems. But it is the implementation. > > Bash has HIST_CONTROL, HISTFILESIZE and HISTSIZE (at least) to let us > control how *files* are kept, including history files (not only memory > commands). The only one of those that acts on a file is HISTFILESIZE. > I think it's a problem with Bash and that it should be addressed by > Bash, directly or not (since you point to Readline). Thank you. You have reported the issue. I have looked at it before, but I concluded that it was not the highest priority thing I could be spending my limited development time doing. You are free to, and I encourage you to, modify bash to use a file-based history mechanism and to implement some kind of synchronization between processes that use it. I would be glad to look at your work. If you want to take a shot at solving the general problem, great. If you don't want to, take a look at the hist_erasedups() function I referred to in my message. There's a little more bookkeeping you'd have to do if you put it into bash, but that should be straightforward. I'd appreciate the help, and you would solve your problem. > And keeping an open and apparently unseen issue in Savannah is bad. Even > if the decision would be what you said in this message, the assumed > improvement I had (and have seen in others) before posting it there > would not feel abandoned. Well, ... I changed the status to `postponed'. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
Re: Savannah and (getting old) issue 108530 reported there
I'm surprised to read you saying that this is not a problem with Bash. I use Bash as my shell. As configure it (from its appropriate config file). And I get results opposite to what would be expected. And you say there is no problem with bash? Bash does not only deal with in memory lists because it reads the history from the file .bash_history when we open a new session. It will read history files with duplicate commands it wrote before, although we configured for not doing this. Bash has HIST_CONTROL, HISTFILESIZE and HISTSIZE (at least) to let us control how *files* are kept, including history files (not only memory commands). I think it's a problem with Bash and that it should be addressed by Bash, directly or not (since you point to Readline). And keeping an open and apparently unseen issue in Savannah is bad. Even if the decision would be what you said in this message, the assumed improvement I had (and have seen in others) before posting it there would not feel abandoned. Well, ... -- Balaco On Fri, May 15, 2015, at 12:18, Chet Ramey wrote: > On 5/15/15 8:44 AM, Balaco Baco wrote: > > I have this issue, and talking with several people and searching around, > > I see that this seems to be a recurring problem for many users. > > > > Some just "fix" it around by using a N times bigger history than they > > wished. Others just consider it a "bug that exists, but won't do nothing > > about it". > > This isn't a bug. Readline (and bash) only deals with in-memory history > lists -- the history facilities are not intended to, nor do they, > operate on disk files other than reading and writing them. There are > also no facilities for sharing history files between sessions other > than synchronizing the history file after each command. > > If you want to remove duplicates from a history file, you have to read > it into memory, use the existing history functions to operate on it, > and write it. There is a program (hist_erasedups.c) in the readline-6.3 > examples subdirectory that shows how to do that. > > -- > ``The lyf so short, the craft so long to lerne.'' - Chaucer >``Ars longa, vita brevis'' - Hippocrates > Chet Ramey, ITS, CWRUc...@case.edu > http://cnswww.cns.cwru.edu/~chet/ -- http://www.fastmail.com - Does exactly what it says on the tin
Re: Savannah and (getting old) issue 108530 reported there
On 5/15/15 8:44 AM, Balaco Baco wrote: > I have this issue, and talking with several people and searching around, > I see that this seems to be a recurring problem for many users. > > Some just "fix" it around by using a N times bigger history than they > wished. Others just consider it a "bug that exists, but won't do nothing > about it". This isn't a bug. Readline (and bash) only deals with in-memory history lists -- the history facilities are not intended to, nor do they, operate on disk files other than reading and writing them. There are also no facilities for sharing history files between sessions other than synchronizing the history file after each command. If you want to remove duplicates from a history file, you have to read it into memory, use the existing history functions to operate on it, and write it. There is a program (hist_erasedups.c) in the readline-6.3 examples subdirectory that shows how to do that. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
Savannah and (getting old) issue 108530 reported there
I have this issue, and talking with several people and searching around, I see that this seems to be a recurring problem for many users. Some just "fix" it around by using a N times bigger history than they wished. Others just consider it a "bug that exists, but won't do nothing about it". It feels like no one involved with Bash development has looked at it on https://savannah.gnu.org/support/?108530 , except myself. Can you give me a good workaround this? Or any idea, at least? -- Balaco balacob...@imap.cc -- http://www.fastmail.com - Same, same, but different...
