Zsh Mailing List Archive
Messages sorted by:
Reverse Date,
Date,
Thread,
Author
Re: Feature request (#b)...(...)<not empty>
- X-seq: zsh-workers 40636
- From: Sebastian Gniazdowski <psprint2@xxxxxxxxxxxx>
- To: zsh-workers@xxxxxxx
- Subject: Re: Feature request (#b)...(...)<not empty>
- Date: Sat, 25 Feb 2017 09:54:22 -0800
- Dkim-signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=fastmail.com; h= content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=mesmtp; bh=pd+Wjy4oBenrdH1oAXnrtxNE/R 4=; b=LY2HYKVE7m5mtIFYPYaatiddHJy3NtSTfi92wbuvFv1MHj4ymDpAgKBjO+ iuQ9qJwBEIQl5oioJ9GA3qkI9DTG+cEDzUAdlgPUyqoodrBSxgcZOccELgfVrHic 81/RyPO2b202bkY19U2Vzu0SyLN3Dd5XDRL88sGoi3L4OR53A=
- Dkim-signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=smtpout; bh=pd +Wjy4oBenrdH1oAXnrtxNE/R4=; b=G1prvvM3hP3XYsPzz+h34ClUPcnEyc5ob6 YcswLPC1sZdcYZGnCoqr3xeNj/SDOrXeKYP2ltVCsjGh8gFX4RtOtbvd99n35we+ DwQpCKHmgiiia8Lq/Wq38itbSNCk5DNZTbnf+pCRCKyJAjQbsLzQnGMBrwncIyje SL80Ssvzw=
- In-reply-to: <170225084736.ZM22286@torch.brasslantern.com>
- List-help: <mailto:zsh-workers-help@zsh.org>
- List-id: Zsh Workers List <zsh-workers.zsh.org>
- List-post: <mailto:zsh-workers@zsh.org>
- Mailing-list: contact zsh-workers-help@xxxxxxx; run by ezmlm
- References: <1488011830.2241447.892433784.52D183B6@webmail.messagingengine.com> <20170225151315.GA4424@fujitsu.shahaf.local2> <1488037019.2320483.892622496.169D8730@webmail.messagingengine.com> <170225084736.ZM22286@torch.brasslantern.com>
On Sat, Feb 25, 2017, at 08:47 AM, Bart Schaefer wrote:
> ([all-except-fg-or-bg]|[fg]|[bg])#([fgbg]|[bgfg]|[fg]|[bg])
>
> Zsh's scanner will always take the left branch of an alternation if both
> branches will succeed, so arranging this with longest matches first will
Yes and this is interesting, I think I'm about something similar:
% a="abc"; echo ${a//(#b)ab(c)(#c0,1)/x} ${a//(#b)ab(c|)/x}
${a//(#b)ab(|c)/x} "<- last one shows | isn't greedy"
x x xc <- last one shows | isn't greedy
% [[ abc = ab(|c) ]] && echo "I've tried multiple options"
I've tried multiple options
I'm not sure if regexes work this way.. Maybe I'm loosing it for a
moment, but:
[[ abc =~ ab(|c) ]] && echo "I've tried multiple options"
zsh: failed to compile regex: empty (sub)expression
not sure how to test regexes. My point is:
- having | in parentheses behave this way looks like something
implementation-driven, not finite automata driven,
- allowing principle of greediness to be deliberately not followed
creates more rich behavior
Maybe (#n) can be implemented this way, by looking at code and not
following model. To in result extend number of states (number of
behaviors) of the system.
--
Sebastian Gniazdowski
psprint2@xxxxxxxxx
Messages sorted by:
Reverse Date,
Date,
Thread,
Author