Re: parse vs. runtime errors

[Ray Andrews <rayandrews@xxxxxxxxxxx>]

On 20/04/18 12:00 PM, Bart Schaefer wrote:
> On Fri, Apr 20, 2018, 11:31 AM Ray Andrews <rayandrews@xxxxxxxxxxx> 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?