From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17740 invoked by alias); 10 Jan 2017 16:09:29 -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: 40325 Received: (qmail 21833 invoked from network); 10 Jan 2017 16:09:28 -0000 X-Qmail-Scanner-Diagnostics: from out1-smtp.messagingengine.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(66.111.4.25):SA:0(-0.7/5.0):. Processed in 1.184347 secs); 10 Jan 2017 16:09:29 -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.7 required=5.0 tests=RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,T_DKIM_INVALID autolearn=unavailable autolearn_force=no version=3.4.1 X-Envelope-From: d.s@daniel.shahaf.name X-Qmail-Scanner-Mime-Attachments: | X-Qmail-Scanner-Zip-Files: | Received-SPF: none (ns1.primenet.com.au: domain at daniel.shahaf.name does not designate permitted sender hosts) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= daniel.shahaf.name; h=cc: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:x-sasl-enc; s= mesmtp; bh=xgg8LfDozi4o567TzEpmtFhubGE=; b=gxFcmsrBU9HQo9i7vZW10 J4x+JL786LpKdTHIbfg3jE5595Z4mZ+yyFQPzrzAdEzAq6T4oVeBjDt7wW2CFRwZ vM2bUjcu0/06OeRSDXuCvplByzRmFORlQbBS5R0uKgKAcufDsXtTw5/pdPD9f0p9 788GZFzZY98+0MnwnKJFK8= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc: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:x-sasl-enc; s= smtpout; bh=xgg8LfDozi4o567TzEpmtFhubGE=; b=s0+hblMIXBcozMt6RRoh 75ZE9A8vGrPQfRj+nQTSOmBz4zceFDHNVDZJDsDebXyUGKmsN+GOTAGmb8xYx5xz lPCwuAzk+npfjD6NHDPlI/WK0rh7lF72vwdSLeCZnSIn9jZrMZ29MvPq2qtD/5yu Tgo6sbcfyvTJXfKjFBzg5mY= X-ME-Sender: X-Sasl-enc: GmZklB1wLfx8kVEHTcr/FoTtaqZ3JGwo+3HPw+FdrJDf 1484064562 Date: Tue, 10 Jan 2017 16:05:59 +0000 From: Daniel Shahaf To: Phil Pennock Cc: zsh-workers@zsh.org Subject: Re: [PATCH] Document echo \c behaviour Message-ID: <20170110160559.GA4660@fujitsu.shahaf.local2> References: <20170109203209.GA13324@breadbox.private.spodhuis.org> <20170110035259.GA31866@fujitsu.shahaf.local2> <20170110093931.GA13581@tower.spodhuis.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20170110093931.GA13581@tower.spodhuis.org> User-Agent: Mutt/1.5.23 (2014-03-12) Phil Pennock wrote on Tue, Jan 10, 2017 at 09:39:31 +0000: > On 2017-01-10 at 03:52 +0000, Daniel Shahaf wrote: > > Thanks; I pushed the first hunk. I didn't push the second one because > > I don't think it's required. If you disagree then make your case ;-). > > The behaviour is bug-ass crazy nuts and needs justification. Every > other escape sequence is a character which is inserted; \c was always > a special case for "suppress the following newline", but "truncate > _everything_ else" from an _escape_ sequence is ... face-palm worthy. > > It warrants explanation as to why it's so counter-intuitive. In that case, I would word it differently; for example: diff --git a/Doc/Zsh/builtins.yo b/Doc/Zsh/builtins.yo index af336ef..091bd49 100644 --- a/Doc/Zsh/builtins.yo +++ b/Doc/Zsh/builtins.yo @@ -467,6 +467,9 @@ sitem(tt(\u)var(NNNN))(unicode character code in hexadecimal) sitem(tt(\U)var(NNNNNNNN))(unicode character code in hexadecimal) endsitem() +Note that tt(\c), unlike all other escapes, discards all following characters +as well. + pindex(BSD_ECHO, use of) The tt(-E) flag, or the tt(BSD_ECHO) option, can be used to disable these escape sequences. In the latter case, tt(-e) flag can be used to However, I still don't think repetition is needed. The purpose of the manual is to document the shell's behaviour, and the sitem() line on master acheives that. It's not as if people are going to run into this behaviour unexpectedly; nobody has ever written . c=${"${:-abcdefghijklmnopqrstuvwxyz}"[RANDOM % 26]} s="foo\\$cbar" eval "echo \"$s\"" | grep -q bar assert($? == 0) . in production code. ;-) Let's see what others think. > > P.S. Overly-literal-reading corner: doesn't "All characters following... > > will be ignored" mean that «echo 'foo\cbar' 'baz' 'qux'» should be > > equivalent to «echo 'foo\cbar' '' ''»? I.e., print «foo» followed by > > two trailing spaces? > > Sounds right. For comparison, the 'printf' spec has plugged this hole: * '\c' , which shall not be written and shall cause printf to ignore any remaining characters in the string operand containing it, any remaining string operands, and any additional characters in the format operand > Take it up with the Austin Group. I believe that Bart is > masochistic enough to pay attention in those arenas and might be willing > to raise it as a spec bug. > > (I tried following AG for a while, and ran away) Understood. Cheers, Daniel