From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <zsh-workers-return-35713-mason-zsh=primenet.com.au@zsh.org>
Received: (qmail 18549 invoked by alias); 7 Jul 2015 11:54:40 -0000
Mailing-List: contact zsh-workers-help@zsh.org; run by ezmlm
Precedence: bulk
X-No-Archive: yes
List-Id: Zsh Workers List <zsh-workers.zsh.org>
List-Post: <mailto:zsh-workers@zsh.org>
List-Help: <mailto:zsh-workers-help@zsh.org>
X-Seq: 35713
Received: (qmail 8337 invoked from network); 7 Jul 2015 11:54:38 -0000
X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on f.primenet.com.au
X-Spam-Level: 
X-Spam-Status: No, score=-6.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_HI,
	RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,SPF_HELO_PASS autolearn=ham
	autolearn_force=no version=3.4.0
X-AuditID: cbfec7f4-f79c56d0000012ee-50-559bbdf93a86
Date: Tue, 07 Jul 2015 12:54:30 +0100
From: Peter Stephenson <p.stephenson@samsung.com>
To: zsh workers <zsh-workers@zsh.org>
Subject: Re: nohistsubstpattern and :s//
Message-id: <20150707125430.0c0c6f44@pwslap01u.europe.root.pri>
In-reply-to: <20150707121535.5d228e2f@pwslap01u.europe.root.pri>
References:
 <CAHYJk3SRsTbop_7EO2E1LoG=gYL=TL5gbbxJzzkWPu2NmA-7cA@mail.gmail.com>
 <150704170147.ZM26204@torch.brasslantern.com>
 <20150705113033.693cd5d6@ntlworld.com>
 <150705141116.ZM22386@torch.brasslantern.com>
 <20150706094906.55e57598@pwslap01u.europe.root.pri>
 <150706135107.ZM4131@torch.brasslantern.com>
 <20150707121535.5d228e2f@pwslap01u.europe.root.pri>
Organization: Samsung Cambridge Solution Centre
X-Mailer: Claws Mail 3.7.9 (GTK+ 2.22.0; i386-redhat-linux-gnu)
MIME-version: 1.0
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: 7bit
X-Brightmail-Tracker:
 H4sIAAAAAAAAA+NgFjrKLMWRmVeSWpSXmKPExsVy+t/xK7o/984ONbjaKGtxsPkhkwOjx6qD
	H5gCGKO4bFJSczLLUov07RK4MlpvdbIV7GCpOHFgAUsD4wbmLkZODgkBE4mGpcdYIWwxiQv3
	1rN1MXJxCAksZZT49OoWC4Qzg0liwY2bUM5WRokfp/aDtbAIqEp823oezGYTMJSYumk2I4gt
	AhRv/v6PBcQWFtCQaPx6nA3E5hWwl/ix5AJYPaeAg8TNz4vYIYZ+Y5J4390B1sAvoC9x9e8n
	Joib7CVmXjnDCNEsKPFj8j2wGmYBLYnN25pYIWx5ic1r3oL9IySgLnHj7m72CYxCs5C0zELS
	MgtJywJG5lWMoqmlyQXFSem5hnrFibnFpXnpesn5uZsYIYH7ZQfj4mNWhxgFOBiVeHhvSMwO
	FWJNLCuuzD3EKMHBrCTCq1sKFOJNSaysSi3Kjy8qzUktPsQozcGiJM47d9f7ECGB9MSS1OzU
	1ILUIpgsEwenVAPjmsobexIcnm4p+fBx40xdifSJKtu38lzdoPpn3T3HwsDdt09ovBWNZA17
	qvvE76V+hNxpO6HLkZ9cjxgUTU7rTHaOLpPMOLBKOKViiwi7qqpX+M6w1wJtCX5Lrvo+8UqV
	e84dF2a+Ye11Tr7onZMC7/CH8DMyP3R8ERGwe+9Vhpye8MrnzslKLMUZiYZazEXFiQDupkYR
	WAIAAA==

On Tue, 7 Jul 2015 12:15:35 +0100
Peter Stephenson <p.stephenson@samsung.com> wrote:
> > torch% a=(abc dbe fbg)
> > torch% unset b
> > torch% print ${a:gs/b/$b/}  
> > a d f
> 
> Perhaps the line is turning into "a$bc", "d$be", "f$bg" before the
> substitution?
> 
> This is new:  the existing code gives
> 
> ac de fg
> 
> so maybe this is a clue to why the current code works the way it does.

Hmm, it seems to have gone back to the old way after a full
recompilation --- unless there's something flaky in the memory
or pointer management.

pws