parse vs. runtime errors

parse vs. runtime errors

[Ray Andrews]

How come:

[ .... ]]

is only caught as an error at runtime?  The error kills anything 
remaining on the same line, but subsequent linesexecute as normal.  I 
find most errors kill the entire parse, but there are some few that 
survive parse but throw the error at runtime.  Why is that?  It's a bit 
annoying that the runtime error can be buried in output and so not be 
noticed, and it seems like it would have to be an error at parse too.  
Either way, can I ask zsh to always make any error stop everything and 
make itself known?  I'll often do something like:

$ . func-file; func arg1 arg2

... and if 'func-file' has some bug in the contained source of 'func 
()', the older version of 'func' just runs anway and one does not see 
the error messageif the output scrolls off the screen.  True, one might 
not be so lazy and source the file, then run the command, but still it 
would be nice if there was some way of making zsh always stop whatever 
it is doing when any code error shows up.

Re: parse vs. runtime errors

[Bart Schaefer]

[-- Attachment #1: Type: text/plain, Size: 592 bytes --]

On Fri, Apr 20, 2018, 11:31 AM Ray Andrews <rayandrews@eastlink.ca> wrote:

> How come:
>
> [ .... ]]
>
> is only caught as an error at runtime?


"[" is a command (synonym for "test") and not a token, and "]]" is only a
token when balanced with "[[".

  The error kills anything
> remaining on the same line


That would depend on how the remaining commands are separated from this one.

Either way, can I ask zsh to always make any error stop everything and
> make itself known?


That's what "setopt errexit" is for, although that mostly applies to
scripts rather than interactive shells.

Re: parse vs. runtime errors

[Ray Andrews]

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