From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17060 invoked by alias); 21 Apr 2018 01:49:04 -0000 Mailing-List: contact zsh-users-help@zsh.org; run by ezmlm Precedence: bulk X-No-Archive: yes List-Id: Zsh Users List List-Post: List-Help: List-Unsubscribe: X-Seq: 23360 Received: (qmail 21490 invoked by uid 1010); 21 Apr 2018 01:49:04 -0000 X-Qmail-Scanner-Diagnostics: from mta02.eastlink.ca 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(24.224.136.13):SA:0(-2.6/5.0):. Processed in 1.830949 secs); 21 Apr 2018 01:49:04 -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=-2.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_LOW, SPF_PASS autolearn=ham autolearn_force=no version=3.4.1 X-Envelope-From: rayandrews@eastlink.ca X-Qmail-Scanner-Mime-Attachments: | X-Qmail-Scanner-Zip-Files: | MIME-version: 1.0 Content-transfer-encoding: 8BIT Content-type: text/plain; charset=utf-8; format=flowed X-Authority-Analysis: v=2.3 cv=dfKuI0fe c=1 sm=1 tr=0 a=RnRVsdTsRxS/hkU0yKjOWA==:117 a=RnRVsdTsRxS/hkU0yKjOWA==:17 a=IkcTkHD0fZMA:10 a=gir0-LH0AAAA:8 a=dc6c5kORloUWW-rAHtIA:9 a=QEXdDO2ut3YA:10 a=aLewGyoHDmJ4ULJHWpSz:22 X-EL-IP-NOAUTH: 24.207.101.9 Subject: Re: parse vs. runtime errors To: zsh-users@zsh.org References: From: Ray Andrews Message-id: <19541cbf-809a-4809-b5ed-a9969e90d1d9@eastlink.ca> Date: Fri, 20 Apr 2018 18:48:56 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 In-reply-to: Content-language: en-CA On 20/04/18 12:00 PM, Bart Schaefer wrote: > On Fri, Apr 20, 2018, 11:31 AM Ray Andrews wrote: > > > "[" is a command (synonym for "test") and not a token, and "]]" is only a > token when balanced with "[[". Probably way over my head.  I expect the former goes back to the beginning of shells so is written in stone.  The latter seems 'obviously' strange so  I expect there's a good reason for it, but it sure is counter intuitive.  Still, why/how can it be acceptable at parse but not at run?  Perhaps because it is theoretically completeable/resolvable at parse but in practice turns out to be a dead end at run?  That is, one might write something that ends up with that construction not being an error? at runtime? > > That's what "setopt errexit" is for, although that mostly applies to > scripts rather than interactive shells. > Yeah, no luck: test1 () { setopt errexit [ "$1" = 'two' ]] && echo that was two echo that was three } 16 /aWorking/Zsh/Source/Wk 3 $ . test 16 /aWorking/Zsh/Source/Wk 3 $ test1 two test1:[:4: ']' expected that was three ... so it didn't abort the function.  Any other way?