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.1 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FROM,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 c43ed013 for ; Thu, 12 Sep 2019 02:08:09 +0000 (UTC) Received: (qmail 14926 invoked by alias); 12 Sep 2019 02:07:59 -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: 44756 Received: (qmail 27704 invoked by uid 1010); 12 Sep 2019 02:07:59 -0000 X-Qmail-Scanner-Diagnostics: from mail-vs1-f68.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.217.68):SA:0(-2.0/5.0):. Processed in 2.537759 secs); 12 Sep 2019 02:07:59 -0000 X-Envelope-From: sgniazdowski@gmail.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.217.68 as permitted sender) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=4xyiLwOEbRHTSEJKJDyyIuuQ+GoXAT2tBl+IRjUrHL0=; b=eI1G9HRrI1fc5l1V4FzgavsqZQFFLvxvpuZcu/iG77KO+ncLykB6jw51kGeHqXkFQW i/bBC6YpCryX6eat2YUiw/5QIB3mGpCoz84tlK613p47gpmVkFylr6gsbmKWiot6nGcl oeCAo63kYxic18SYGmW4VmHTRGSMAb2JdhMfaZqaBoIANFhDRkuA/QScISTeX8gaMzOP PVFvEHGackktSt/TSR+0vXcUPHs6T839MBhQtlbC9cxu6u73sh2LuP5R7NzC00+rb+tB UYGog7LL8GNguXVo8gBQrEj2VivLNoqiU3apLY/uK2o5+pHw1XoKWYHEfX7hz4uc7kaN +7mQ== 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=4xyiLwOEbRHTSEJKJDyyIuuQ+GoXAT2tBl+IRjUrHL0=; b=OOZbI+RSDdFZCDis6N1T3una48kVDN46QCR1wFPIiqbWKqjk3qdPVahb/+KDx2i0i2 7rJUGYFt4uO3T01Vti0ongpDbKDyMwSoFab47hcM3B5lBJvqRSe4fI8Q6LTutNTH4a9e VvrrUMG7xWSGiIWeUPS7kvPIRW7hS44TxrGDg4SJugDrHiQqjjFMDw2ZekAIFG4cimJp D8C85qFYyf7KoeN5hySZxmz1WHtqPXgcMUf/HWH+TOJxVn3tdo357tXc2qEpw8Ij1p9g vUYi0vy+HQXPljd53VMn6g+9nhVBdK6hcmn4kg6TGK5uwunpdPkkgyyp2XdV8AUUyk4Y ozSw== X-Gm-Message-State: APjAAAUr2nF7VfEFOabCbRWLlP/7eENmcQRzcomtkIkAYABEOWKqxpNW XLVhD9d/RI03kiY3fQXsXjPkqYqP15PlDH65QyOOETCy X-Google-Smtp-Source: APXvYqwjTNJjixNrgq6ICQxmAAP1Hb+ryRsAIz8BySQSuEfFqd5VBzoa1OkFbdh/9bRNWvaS2hSJGv2Tjvrufrn9UwU= X-Received: by 2002:a67:e3c2:: with SMTP id k2mr20532237vsm.77.1568254043549; Wed, 11 Sep 2019 19:07:23 -0700 (PDT) MIME-Version: 1.0 References: <20190907150741.jwztdoslrvk5j7nk@chaz.gmail.com> <20190907201954.dn2nve65wqk4muvc@chaz.gmail.com> In-Reply-To: From: Sebastian Gniazdowski Date: Thu, 12 Sep 2019 04:06:45 +0200 Message-ID: Subject: Re: [PATCH] Support the mksh's ${|func;} substitution To: Bart Schaefer Cc: Zsh hackers list Content-Type: text/plain; charset="UTF-8" On Thu, 12 Sep 2019 at 03:03, Bart Schaefer wrote: > > On Wed, Sep 11, 2019 at 5:09 PM Sebastian Gniazdowski > wrote: > > > > So you've implemented ${|code;} for mksh? > > Good grief, no. I have never even (knowingly) USED mksh. I just said > that IF it had been me, I probably would have made a different syntax > choice. Ah, I've misread it then. > > Ok, but this could use ...RLD; REPLY=HERE'. The use of reply is just > > to simplify, i.e. to use different vars for the (x) embedded code and > > for the substitution code? > > Again, by analogy to the glob qualifier -- the input ($REPLY) is a > scalar, the output ($reply) is an array (which might or might not get > string-ified by double-quoting). > > In an (e) glob, REPLY is set to each possible file name in turn, but > $reply can provide multiple names to the final result. I'm assuming > you want ${(x...)array} to apply to each array element in turn, not to > the entire array at once, so again REPLY is a scalar (each array > element) but could be replaced by multiple elements in $reply. That's interesting. The mapping could then look like: array( "a" "b c" "d" ) func() { reply=( ${=REPLY} ); } array=( ${(x^func^)array} ) and it would result in FOUR array elements, not three. This is a concrete extension from the mapping via //(#m)*/${(x):-func}, which cannot extend the array (nor contract it). I think that in order to allow contraction of the result, the (x) flag could use only reply, without REPLY as opposed to the (e), unless we do that reply being just set invalidates REPLY and allows the empty result. But also, the advanced (x) flag is quite complex. It might be a good reason to lower the complexity by making the flag substitute only reply contents. > I think you grasped it, yes. > > Whether the syntax ${(x+func)...} would call "func" once for each > array element (again by analogy to glob (e+func)) would be an > implementation choice. Too bad (x) for globs and (e) for parameters > already have other meanings, so there's no way to make them use the > identical key character. Why only one + in the examples? (I've tried this syntax with (e), it doesn't seem to support it). I think that yes, it should call the func per each array element, to allow the expanding / contracting featured mapping. Also, I wonder what other interesting things can result from the 2-step code/data providing to the substitution. > > > > I think that the (x) flag should be at the top of the list, first. > > > > > > That can't be right. > > > > Ok, I've did hurry too much. The :- is point 7. > > This sounds more sensible. Great. It seems that we're getting close to a final "draft". -- Sebastian Gniazdowski News: https://twitter.com/ZdharmaI IRC: https://kiwiirc.com/client/chat.freenode.net:+6697/#zplugin Blog: http://zdharma.org