From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2003 invoked by alias); 17 Jul 2014 13:05:22 -0000 Mailing-List: contact zsh-workers-help@zsh.org; run by ezmlm Precedence: bulk X-No-Archive: yes List-Id: Zsh Workers List List-Post: List-Help: X-Seq: 32881 Received: (qmail 2865 invoked from network); 17 Jul 2014 13:05:11 -0000 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=-0.7 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE, RCVD_NUMERIC_HELO,SPF_HELO_PASS,T_FSL_HELO_BARE_IP_2 autolearn=no version=3.3.2 X-Injected-Via-Gmane: http://gmane.org/ To: zsh-workers@zsh.org From: Augie Fackler Subject: Re: history-incremental-search-backward weird behavior for multiline commands in 5.0.x Date: Thu, 17 Jul 2014 13:02:31 +0000 (UTC) Message-ID: References: <140716091007.ZM2526@torch.brasslantern.com> <20140716173056.6515047e@pwslap01u.europe.root.pri> <140716105417.ZM2695@torch.brasslantern.com> <20140716195959.3014d4bf@pws-pc.ntlworld.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: sea.gmane.org User-Agent: Loom/3.14 (http://gmane.org/) X-Loom-IP: 74.125.59.145 (Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/35.0.1916.153 Safari/537.36) Peter Stephenson ntlworld.com> writes: > > On Wed, 16 Jul 2014 10:54:17 -0700 > Bart Schaefer brasslantern.com> wrote: > > On Jul 16, 5:30pm, Peter Stephenson wrote: > > } Subject: Re: history-incremental-search-backward weird behavior for multil > > } > > } I think the load parsing must be broken --- I'm pretty sure it always > > } used doubled backslashes to signal this and it obviously used to work. > > > > This appears to have somethign to do with workers/28332 and 28339, but > > I'm not yet sure exactly what. > > Certainly if I comment out code in readhistline() as follows, it reads > back in again the same as 4.3.11 (which just happens to be the first old > version that worked). > > else { > buf[len - 1] = '\0'; > if (len > 1 && buf[len - 2] == '\\' /*&& > (len < 3 || buf[len - 3] != '\\')*/) { > buf[--len - 1] = '\n'; > if (!feof(in)) > return readhistline(len, bufp, bufsiz, in); > } > } > > However, that's not the whole story --- the extended history is written > out with each segment: > > : 1405536461:0;echo foo \\ > : 1405536465:0;bar \\ > : 1405536465:0;rod > > which can't be right because it reads back as > > echo foo \ > : 1405536465:0;bar \ > : 1405536465:0;rod > > in both the latest code and 4.3.11. The latter saves without the > extended history, > > : 1405536927:0;echo foo1 \\ > bar1 \\ > rod1 I just posted a patch for this and then saw the thread (not subscribed, so hopefully gmane does the right thing on this response). I came up with the same fix yesterday and have been using it for a day - with the patch applied, zsh 5.0.x will write out history the same way 4.3.11 did. It *won't* go back and fix up mangled history files that zsh 5 trashed, so you get the extended history droppings in the multiline entries. I think you could fix a corrupted history file by turning off extended history, loading it, closing zsh, and then turning extended history back on (once all your zsh 5 installations were fixed, naturally). I have not tested that theory since it's trivial enough to load the command up in emacs and use kill-rectangle on it. > > pws > >