From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <zsh-users-return-20751-mason-zsh=primenet.com.au@zsh.org>
Received: (qmail 22285 invoked by alias); 13 Oct 2015 21:42:18 -0000
Mailing-List: contact zsh-users-help@zsh.org; run by ezmlm
Precedence: bulk
X-No-Archive: yes
List-Id: Zsh Users List <zsh-users.zsh.org>
List-Post: <mailto:zsh-users@zsh.org>
List-Help: <mailto:zsh-users-help@zsh.org>
X-Seq: 20751
Received: (qmail 15887 invoked from network); 13 Oct 2015 21:42:15 -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=-1.9 required=5.0 tests=BAYES_00 autolearn=ham
	autolearn_force=no version=3.4.0
X-Authority-Analysis: v=2.1 cv=T/C1EZ6Q c=1 sm=1 tr=0
 a=TDXRqai3AtB4qfuLBL55xA==:117 a=TDXRqai3AtB4qfuLBL55xA==:17 a=N659UExz7-8A:10
 a=4QJXM5EAPUOHDcwu1UkA:9 a=NsU9p7NwQiDDbZYg:21 a=EIo3z2POAquFHzgA:21
 a=pILNOxqGKmIA:10
Message-id: <561D7AB4.7030206@eastlink.ca>
Date: Tue, 13 Oct 2015 14:42:12 -0700
From: Ray Andrews <rayandrews@eastlink.ca>
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Icedove/31.7.0
MIME-version: 1.0
To: zsh-users@zsh.org
Subject: Re: subsitutions and beginning of lines.
References: <561AB49A.4060801@eastlink.ca>
 <20151011210902.566de251@ntlworld.com> <561AEB2F.8030808@eastlink.ca>
 <20151012103455.5f6159d7@pwslap01u.europe.root.pri>
 <561BD55C.3080006@eastlink.ca> <561BE8DC.7060506@eastlink.ca>
 <151012192908.ZM15508@torch.brasslantern.com> <561C717A.1030202@eastlink.ca>
 <151012220313.ZM16595@torch.brasslantern.com> <561C95A9.7020508@eastlink.ca>
 <151013125819.ZM30782@torch.brasslantern.com>
In-reply-to: <151013125819.ZM30782@torch.brasslantern.com>
Content-type: text/plain; charset=windows-1252; format=flowed
Content-transfer-encoding: 7bit

On 10/13/2015 12:58 PM, Bart Schaefer wrote:
> The normal thing when capturing $(...) in an array context is to treat
> all adjacent (consecutive) whitespace (characters listed in $IFS) as a
> single word break, yes.  But the spaces aren't being "stripped down to
> a single one".  They're being stripped out ENTIRELY, leaving nothing.
> It's when putting the array back together into a string again that a
> single space is inserted between words.

Ah ... a subtle point but critical.  Yes ... I need to 'think array' not 
'think string'.
I apologize for my C headedness which refuses to go away.
>      ${${(f)"$(eval history $nnumber $sstring)"}##<->:}

I couldn't get the substitution there to work, but this works fine:

	print -l ${${(f)"$(eval history $nnumber $sstring)"}/ #<->??/}

... and I can see that the inner '$(eval ..)' layer will not
molest any spaces at all and each output line is an element unto
itself in an array split on newlines which is then sent for surgery
and then printed one line per element.  It's so easy to get it
wrong, but when you get it right, it's down right elegant and not
really obscure at all.

BTW, is there some way of asking history not to search
thru a given number of entries, but to continue searching up to
a given number of hits? Making syntax up:

history -#10 intricate_command

... I find when searching, that what I'm really wanting is a
reasonable number of hits to select from, and my choice of
number for the switch is just a guess which I scale up or
down to achieve some number of hits.  I might know that
some time in the last year I entered some command that I'd
like back and I don't really care how far back in history
it was, I just want history to scan backwards until
a match (or several) is found.  Can it be done? If not
it would be a feature.