From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <zsh-users-return-19619-mason-zsh=primenet.com.au@zsh.org>
Received: (qmail 21370 invoked by alias); 20 Dec 2014 03:55:34 -0000
Mailing-List: contact zsh-users-help@zsh.org; run by ezmlm
Precedence: bulk
X-No-Archive: yes
List-Id: Zsh Users List <zsh-users.zsh.org>
List-Post: <mailto:zsh-users@zsh.org>
List-Help: <mailto:zsh-users-help@zsh.org>
X-Seq: 19619
Received: (qmail 10776 invoked from network); 20 Dec 2014 03:55:33 -0000
X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on f.primenet.com.au
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_LOW
	autolearn=ham version=3.3.2
X-Authority-Analysis: v=2.1 cv=T/C1EZ6Q c=1 sm=1 tr=0
 a=nXUbkqBeGw4q4gDV/Ctilg==:117 a=nXUbkqBeGw4q4gDV/Ctilg==:17 a=G8GL833Es-AA:10
 a=IkcTkHD0fZMA:10 a=oxMyfWdmtyIldkdHEUUA:9 a=QEXdDO2ut3YA:10
Message-id: <5494F332.7000008@eastlink.ca>
Date: Fri, 19 Dec 2014 19:55:30 -0800
From: Ray Andrews <rayandrews@eastlink.ca>
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Icedove/31.2.0
MIME-version: 1.0
To: zsh-users@zsh.org
Subject: Re: surprise with echo
References: <54937E5B.2020008@eastlink.ca>
 <141218190653.ZM16331@torch.brasslantern.com>
 <CABx2=D8EU+uFXizT99ETXMZKScrFAeyEezeV9NgsLe8=Sdv4Bg@mail.gmail.com>
 <20335.1418988086@thecus.kiddle.eu>
 <CABx2=D-a9SnuSUgopZMQMnMB=ve9WZ02+uFfOsee2WbOogkddQ@mail.gmail.com>
In-reply-to:
 <CABx2=D-a9SnuSUgopZMQMnMB=ve9WZ02+uFfOsee2WbOogkddQ@mail.gmail.com>
Content-type: text/plain; charset=utf-8; format=flowed
Content-transfer-encoding: 7bit

On 12/19/2014 06:58 PM, Kurtis Rader wrote:
> Fair enough. And I don't have any objection to the options per se. In 
> fact I think the behavior provided by the rc_quotes option should have 
> been the default from day one (hindsight is wonderful). What I do 
> object to is the implication that the semantics of the rc_expand_param 
> option will match that of the rc shell. Yes, the zsh documentation is 
> quite clear that isn't true but the name of the option can easily lead 
> someone to think otherwise. 
My two cents would be (well, er, my 1/2 cent), that it should be the 
default, *but* that the little surprise should not be there, a) because 
that would be more true to the name of the option, and b) because it 
seems harsh to kill an entire string because one element in it is null.  
Does that sort of thing happen anywhere else? c) Because the doctrine of 
least surprise should be followed.  OTOH Bart just showed how the 
surprise can be avoided so ....