From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18100 invoked from network); 3 Oct 1999 08:16:37 -0000 Received: from sunsite.auc.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 3 Oct 1999 08:16:37 -0000 Received: (qmail 22394 invoked by alias); 3 Oct 1999 08:15:17 -0000 Mailing-List: contact zsh-workers-help@sunsite.auc.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 8124 Received: (qmail 22387 invoked from network); 3 Oct 1999 08:15:15 -0000 From: "Bart Schaefer" Message-Id: <991003081510.ZM31464@candle.brasslantern.com> Date: Sun, 3 Oct 1999 08:15:10 +0000 In-Reply-To: <9909280854.AA28230@ibmth.df.unipi.it> Comments: In reply to Peter Stephenson "Re: Weird behaviour with certain PS1-sequences" (Sep 28, 10:54am) References: <9909280854.AA28230@ibmth.df.unipi.it> X-Mailer: Z-Mail (5.0.0 30July97) To: zsh-workers@sunsite.auc.dk (Zsh hackers list) Subject: PATCH: 3.1.6: promptexpand (Re: Weird behaviour with certain PS1-sequences) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii On Sep 28, 10:54am, Peter Stephenson wrote: } Subject: Re: Weird behaviour with certain PS1-sequences } } Dan Nelson wrote: } > % zsh -f } > % PROMPT="%m %n %/ %%" } > dan dan /home/dan % TERM=dumb } > dan dan /home/dan % } > ^ blanks start here and don't stop } } Yes, I can see this, and what's going wrong, in the refresh code. } Unfortunately I'm not sure I understand the logic well enough to fix it, } though if Geoff doesn't get around to it I will have to try. I was looking at this because 3.0.6 has the same bug, and I can't figure out what Geoff thinks is happening either. There doesn't seem to ever be any reason to output more than `ct' characters unless you're reprinting from the beginning of the line (which is what the block lower down does, but after sending a '\r'). However, while experimenting with forcing zsh to take all three branches of that code, I discovered that there's a bug in promptexpand() when the %{...%} construct is used -- it leaves garbage characters in the string beyond the end of the prompt. The following should take care of it. This reminds me, though, that a while back somebody noticed that zalloc() called calloc() rather than malloc() and "fixed" it. I wonder if there are other bugs lurking around because callers of zalloc() assume that they are getting a zero'd buffer? Index: Src/prompt.c =================================================================== @@ -161,7 +161,7 @@ rstring = rs; Rstring = Rs; fm = s; - bp = bufline = buf = zalloc(bufspc = 256); + bp = bufline = buf = zcalloc(bufspc = 256); bp1 = NULL; trunclen = 0; putpromptchar(1, '\0'); -- Bart Schaefer Brass Lantern Enterprises http://www.well.com/user/barts http://www.brasslantern.com