From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17359 invoked by alias); 9 Mar 2015 17:47:31 -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: 34690 Received: (qmail 29717 invoked from network); 9 Mar 2015 17:47:29 -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=Mh2YLme1CK41vfYz+ySudA==:117 a=Mh2YLme1CK41vfYz+ySudA==:17 a=VNsaWKQvMhEA:10 a=N659UExz7-8A:10 a=x5S305G_LJujZ4sg2jUA:9 a=pILNOxqGKmIA:10 Message-id: <54FDDCAD.8030305@eastlink.ca> Date: Mon, 09 Mar 2015 10:47:25 -0700 From: Ray Andrews User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Icedove/31.4.0 MIME-version: 1.0 To: zsh-workers@zsh.org Subject: Re: Aliasing separators (Re: grammar triviality with '&&') References: <20150304144756.GA27231@ypig.lip.ens-lyon.fr> <150304175112.ZM19818@torch.brasslantern.com> <20150305100638.55631238@pwslap01u.europe.root.pri> <150305090720.ZM8441@torch.brasslantern.com> <20150305174011.0be5a31e@pwslap01u.europe.root.pri> <150305174240.ZM8732@torch.brasslantern.com> <20150306094039.3d968c63@pwslap01u.europe.root.pri> <150306112628.ZM9769@torch.brasslantern.com> <20150307155252.75848f74@ntlworld.com> <150307131008.ZM17180@torch.brasslantern.com> <20150309114629.GF26461@xvii.vinc17.org> <20150309163309.44a00910@pwslap01u.europe.root.pri> <150309100318.ZM12484@torch.brasslantern.com> In-reply-to: <150309100318.ZM12484@torch.brasslantern.com> Content-type: text/plain; charset=windows-1252; format=flowed Content-transfer-encoding: 7bit On 03/09/2015 10:03 AM, Bart Schaefer wrote: > My vote (perhaps obviously) would be to back it out, fix the issue with > "{" / catenation and the history, and then consider whether aliasing of > other tokens can be re-introduced. > I'm not competent to vote, but my hope will be that whatever happens will make the code more consistent, reliable,understandable and intuitive, and make usage more predicable and friendly and not open any cans of worms. [ -e file1 ] && do-this ... from the start, I understood that this was friendly ... the parser might have been crabby and demand a complete statement but it is considerate enough to wrap and see what's on the next line before throwing an error. In the same spirit I thought that: [ -e file1 ] && do-this ... would be the same sort of friendliness, with the '&&' automatically checking the previous errorlevel. I thought that is would be impossible for it to parse as anything but it's naive reading, therefore it need not be an error. But if not, it's simply nothing of a real world difficulty. The 'alias' thing seems very scary. I might one day understand aliasing fundamental syntax, but for now the mind reels. Are not things tricky enough already? I hope something good comes from my trivial question ;-)