From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28155 invoked by alias); 19 Sep 2016 20:30:56 -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: X-Seq: 39390 Received: (qmail 1742 invoked from network); 19 Sep 2016 20:30:56 -0000 X-Qmail-Scanner-Diagnostics: from mail-pf0-f195.google.com by f.primenet.com.au (envelope-from , uid 7791) with qmail-scanner-2.11 (clamdscan: 0.99.2/21882. spamassassin: 3.4.1. Clear:RC:0(209.85.192.195):SA:0(0.0/5.0):. Processed in 0.828025 secs); 19 Sep 2016 20:30:56 -0000 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=T_DKIM_INVALID autolearn=unavailable autolearn_force=no version=3.4.1 X-Envelope-From: schaefer@brasslantern.com X-Qmail-Scanner-Mime-Attachments: | X-Qmail-Scanner-Zip-Files: | Received-SPF: none (ns1.primenet.com.au: domain at brasslantern.com does not designate permitted sender hosts) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brasslantern-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:date:in-reply-to:comments:references:to:subject :mime-version; bh=TJ9WWB7cuu6WEhNfONEJxMoJz+t2zH+x8eBdgB9soTc=; b=gV6CKqT1RV7hrP+TbmF1hlZ5GbRoX2zUVxrtGGatUMeOwrS1Ko9okUDgy5mz0WiZeT K+fqb+e7g8L84YAM33800LGEg647+WSDsz5XJG34z6sesXv1ycm7PozzFgeQ4LZr7X2P 7SnAz2rYU1PwzX1IvM284bddgVPjK2lU5hQG9yXUn2dvhSaPyUcHLg0tQ/GHlPNWzuFe mLcOW1fUr18ahLDuxt3CpQjnig6e36COcPymcj2u3bhDeAKmt8uBE3rgKFrl3X7NVOgn rh6J0YnWb04FWujvtYwcd/Y8gQB6+WUuJea5asJX9zVVnI1wfBIEHx9dLH02ET80G78y TgTQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:message-id:date:in-reply-to:comments :references:to:subject:mime-version; bh=TJ9WWB7cuu6WEhNfONEJxMoJz+t2zH+x8eBdgB9soTc=; b=l4ujBkC63bzR+/T2s/t3kdBauv4sA7EE9XUGb5EX2aLvwHgeK5+6JZV2NTngBEQ3xd RZJ1N6XNhP9ATtYVl+/Fk0YzP4jZLsjicZwWa24WCxmxQuqinzEB7mkvp04ufZK/gh4S CnxwmpptyV3aEqf8fXa1bLdfWM61RZbjugzA1S+vITbw1/GGrVAqWV/0rtKM5MO4ACuf 6BqoS11KUtZ4o8rs7Vv6b5Pb6Sdopm2OzBosPVAc0WkgqWEYNgVwyxsRvZwFGHU+xMXE 3XqbXjkEHYL228ASBB+17P7221aZk6qCZqRI250Wqrr+63crzyxTk2ygmDUPNFWghVC0 TSTg== X-Gm-Message-State: AE9vXwOHX2etOpd5uBDQv4Aa2heUHfrikZ+VixtdPE4WBGEPNHISw78WdYNDG6e9K57X8g== X-Received: by 10.98.150.157 with SMTP id s29mr16021460pfk.3.1474317048326; Mon, 19 Sep 2016 13:30:48 -0700 (PDT) From: Bart Schaefer Message-Id: <160919133047.ZM28795@torch.brasslantern.com> Date: Mon, 19 Sep 2016 13:30:47 -0700 In-Reply-To: <53992.1474303843@hydra.kiddle.eu> Comments: In reply to Oliver Kiddle "PATCH: print -v with an array" (Sep 19, 6:50pm) References: <53992.1474303843@hydra.kiddle.eu> X-Mailer: OpenZMail Classic (0.9.2 24April2005) To: Zsh workers Subject: Re: PATCH: print -v with an array MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii On Sep 19, 6:50pm, Oliver Kiddle wrote: } } This patch makes print -v check if the variable is an array and if } so, each reuse of the format string will correspond to a separate } array element. [...] printf -v was added } after zsh 5.2 was released so we've no compatibility concern there. } [...] } With a bit of rearrangment of bin_print it would now be possible } to use this to allow more mixing of print options: -f with -c, for } example. When did we get the ability to do "print -z -f ..." It might be useful to have every reuse of the format add a separate entry to the buffer stack. Similarly for "print -s -f" and the history. (Currently -S is silently ignored if -f is given. Hmm. Not sure how that ought to work anyway.) } Alternatives to checking if the variable is an array first would } be a -A option or perhaps making the feature specific to print } (which bash lacks) and not to printf. I'd lean toward the -A option (especially if we alter -z / -s as I just mentioned above). Right now print -v / printf -v can create a variable (for which BTW we are lacking a WARN_CREATE_GLOBAL warning), it'd be nice to create it as an array. I see you've implemented it by building up the array and then doing the assignment all at once, rather than appending one element at a time. This makes it possible to use it for associative arrays, even though it'd be a bit unusual to have the same format for both keys and values. } Back in January, when I wasn't paying attention, Bart wrote: } > - Should "print -v foo bar" write the trailing newline into $foo ? In the } > patch below I've chosen to make -n implicit with -v. This does not } > involve "printf" which always needs an explicit newline. } } I'd suggest we include the trailing newline if the -l option was } specified. Seems it does get included with -c. It's probably a mistake/oversight with -c. The *embedded* newlines always get included. The question is whether print -l one two three four and print -l -v stuff one two three four print "$stuff" should produce identical output, rather than the latter having two consecutive newlines at the end. Whichever way we decide, the same really should also apply to -c. } With print -v the open_memstream stuff might see more usage. Should } we be concerned with more efficient alternatives to the temporary } file fallback? I have no opinion here, except to grumble about ending up with three or four #ifdef'd implementations of the same thing.