From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28169 invoked from network); 7 Jun 1999 02:49:01 -0000 Received: from sunsite.auc.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 7 Jun 1999 02:49:01 -0000 Received: (qmail 3828 invoked by alias); 7 Jun 1999 02:48:57 -0000 Mailing-List: contact zsh-workers-help@sunsite.auc.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 6479 Received: (qmail 3821 invoked from network); 7 Jun 1999 02:48:56 -0000 Date: Sun, 6 Jun 1999 19:48:50 -0700 (PDT) From: Wayne Davison To: Sven Wischnowsky cc: zsh-workers@sunsite.auc.dk Subject: Re: segv with :_correct or :_correct:_approximate In-Reply-To: <199906020637.IAA27444@beta.informatik.hu-berlin.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Wed, 2 Jun 1999, Sven Wischnowsky wrote: > Wayne, this happens when freehistdata() calls removehashnode() > with a histent with he->text==NULL. It's actually slightly worse than that, it would have tried to free the static "curline" structure if it had successfully free'd the structure's data. > (All this with HIST_NO_FUNCTIONS, it tries to remove a function > definition from the history at that time.) Yes, this is the meat of the problem -- remhist() is being called to remove a history line when the function definition did not come from the history -- ouch. (Before my history changes, the code would have successfully lost the last history line from the internal history as a side-effect of completing the current history line.) So, I've got a simple fix for this particular problem (I'll post a patch in a moment), but I think in the long run we need to redesign the "remhist()" stuff. In addition to the problems of when the remhist() function should be called and when it shouldn't, the new SHARE_HISTORY code writes out a history line to the history file right after you type it, and it cannot easily remove the line post facto if the code later decides to call remhist(). I'm thinking that it would be best if we could identify the lines that shouldn't be added to the history file before we save them, rather than removing them afterwards. I see two possible ways to do this. Either come up with a way to identify the non-saved commands earlier, or move the history-saving later. One solution might be to implement a pattern-matching system (an array of regular expressions?) that would identify the lines that should not be remembered. The existing history-removing options (including HIST_IGNORE_SPACE) would be implemented using this system. This would allow the current history-saving code to avoid ever adding these lines to the history in the first place, and would not be affected by things like the defining of functions in completion scripts. (This would also allow someone to easily add a pattern to ignore short commands -- e.g. /^..?$/). ..wayne..