From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-1.0 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, MAILING_LIST_MULTI,RCVD_IN_DNSWL_NONE autolearn=ham autolearn_force=no version=3.4.2 Received: from primenet.com.au (ns1.primenet.com.au [203.24.36.2]) by inbox.vuxu.org (OpenSMTPD) with ESMTP id 257c8ce9 for ; Tue, 10 Sep 2019 19:39:32 +0000 (UTC) Received: (qmail 24748 invoked by alias); 10 Sep 2019 19:39:25 -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: List-Unsubscribe: X-Seq: 44749 Received: (qmail 11412 invoked by uid 1010); 10 Sep 2019 19:39:25 -0000 X-Qmail-Scanner-Diagnostics: from mail-lf1-f65.google.com by f.primenet.com.au (envelope-from , uid 7791) with qmail-scanner-2.11 (clamdscan: 0.101.2/25566. spamassassin: 3.4.2. Clear:RC:0(209.85.167.65):SA:0(-1.9/5.0):. Processed in 2.362525 secs); 10 Sep 2019 19:39:25 -0000 X-Envelope-From: schaefer@brasslantern.com X-Qmail-Scanner-Mime-Attachments: | X-Qmail-Scanner-Zip-Files: | Received-SPF: pass (ns1.primenet.com.au: SPF record at _netblocks.google.com designates 209.85.167.65 as permitted sender) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brasslantern-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=5ALWMKQINjFschnPMZBA87oFw8ueF7Mho0oplHgpE9k=; b=L31wvdqorO0Wk9iSIJs+xIJ+9bLZnO5nPDK/Y4WPk6/l7bu2DTDWL1Sv2JF+KwTt0g Tr7WJRwep+WD8krPDzfGYdPOEV0mf2oP8RkgPqtpk8SonAEHcKyYQbX6D/2NLgpsAc4i qOQoEHYS3DMlwoTOHJkBgVJOU/Jm6Uecda6ZNj9gExvlrfMtKmj6AFiHUbjY+ifQhoN6 fnD4RvIElci9jglPEgLkP8sHZsdhmT+jf07dtsm+X50Moa5T6ow5f2QcF7UzOhhD3aet sY+dIhBHiQBCMPrrITkPpbE38ZKmpYq3xS+FN7f3mYDMCmJv0KU1lgfbr5gkqSZX9lD1 DwZA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=5ALWMKQINjFschnPMZBA87oFw8ueF7Mho0oplHgpE9k=; b=F8oqcl8TJ5VV/SCCAf3UWTpKc+2fBIachaiQm1V9egyofrGorP1kWnRP/liXhRz4im ccW1gcX5qNm327BHn6yQwuS18vogwKpZMIDld3aMASFYVFfyzDKTPQpmnAbAcRVfYuQ+ JX2EhGeGbGWJzSHaeiSTEqpXfnNcU3bYWz8HysKIEbTxvsQQOPewM4aLtGeP2viYHNOy n4K77QU8pdyUuSn+D4EC0Fldkn76byo1J1MjZSBLSEpQEY9nYxqYnoBPGCH4i9h30wGI mpkTbRg9uYZgu7NNsM4G5ZEsJU3IrHH1jaHHGwt75LDiy1v5sl0ZfUZ5tZDoI+pbqJFK DsxQ== X-Gm-Message-State: APjAAAXWOlV5M74vFY79Nt+jEakuGbKu07wQYkq8rZNEFnOqwWezlYm7 tMtTTtwahwUK0a5a7N/CXGHCiMrPtWg5gmjBhfugvw== X-Google-Smtp-Source: APXvYqxUV6DzflBuQfy9lrIRN6JT4x6adydj1msSsFuWqIfht4VXPK7TjHnMycU9BmJp6uuEAe+r7EQ9O9HhyE63v8Q= X-Received: by 2002:a19:ed0f:: with SMTP id y15mr4102957lfy.81.1568144327712; Tue, 10 Sep 2019 12:38:47 -0700 (PDT) MIME-Version: 1.0 References: <20190907150741.jwztdoslrvk5j7nk@chaz.gmail.com> <20190907201954.dn2nve65wqk4muvc@chaz.gmail.com> In-Reply-To: From: Bart Schaefer Date: Tue, 10 Sep 2019 12:38:35 -0700 Message-ID: Subject: Re: [PATCH] Support the mksh's ${|func;} substitution To: Sebastian Gniazdowski Cc: Zsh hackers list Content-Type: text/plain; charset="UTF-8" On Tue, Sep 10, 2019 at 11:21 AM Sebastian Gniazdowski wrote: > > On Tue, 10 Sep 2019 at 07:29, Bart Schaefer wrote: > > > > parser tokens, so the stuff that follows them can be parsed at the > > statement level rather than gobbled up by the parameter substitution > > code. > > Would it be hard to accomplish? Probably not -- it could mostly share the code for $(...), it would just have to have different opening and closing tokens. Without having given it a huge amount of thought, I suspect I might have chosen $(|...) instead of ${|...} had I been implementing for mksh ... but I suppose the idea is that parens imply a subshell where braces imply the current shell. > > I still have a nagging feeling that it should be more like the > > (e^...^) globbing flag, in particular the part about returning arrays > > through reply=(...) but also whether it might look like > > ${(x^code^)var} where "code" would receive the current value of the > > substitution as $REPLY and return the new value in $reply. Your "for" > > example could still I think come out like: > > > > ${(x^eval $REPLY^):-for val (test test3) { > > reply=\$val > > }} > > I'm not following the example. Why there's reply= and not reply+=? Why > in the :- it's reply that's altered, while in (x) there's REPLY? I'm writing by analogy to the (e) glob qualifier. Consider: % touch 'echo HELLO WORLD; reply=HERE' % print e*(e^'eval $REPLY'^) HELLO WORLD HERE So ${(x^'eval $REPLY'^)var} would be analogous to (minus the implied fork) $(REPLY="$var" eval $REPLY print -r -- "${reply[@]}") If you change ${var} to ${:-string} then you get $(REPLY="string" eval $REPLY print -r -- "${reply[@]}") > > Other things that need to be thought about before this gets a go/no-go > > are nested substitutions and how to fit (x) into the order-of-events > > subsect(Rules) as laid out in expn.yo. > > I think that the (x) flag should be at the top of the list, first. That can't be right. It's got to at least be after nested substitution or the parsing for ${...:-...} and similar doesn't make sense, and it's probably got to be after (P) flag handling if not also after double-quoted joining.