`=' expansion causes script/subshell to exit, bug?

`=' expansion causes script/subshell to exit, bug?

[Vasiliy Ivanov]

Hello. Recently I've seen that line like

[[ -x =somebinary ]] || cmd

causes script to exit unexpectedly with message like «/path/to/script:$line: =somebinary not found»,
instead of invoking || cmd and continue executing

some simple tests:

% ( [[ -x =123123 ]] || { print 'ohshi'; exit 2 } )
zsh: 123123 not found <exit code 1>

% ( b=123123; print =$b; print 'ohshi' )                                                  ↑
zsh: 123123 not found

Is it intended behaviour?

% zsh --version
zsh 5.6.2 (x86_64-pc-linux-gnu)

-- 
Regards,
  Vasiliy Ivanov <beelzebubbie.logs@gmail.com>

Re: `=' expansion causes script/subshell to exit, bug?

[dana]

On 27 Sep 2018, at 14:20, Vasiliy Ivanov <beelzebubbie.logs@gmail.com> wrote:
>% ( b=123123; print =$b; print 'ohshi' )
>zsh: 123123 not found
>
>Is it intended behaviour?

That's because of the option nomatch, which is enabled by default and is
documented as follows:

  If a pattern for filename generation has no matches, print an error, instead
  of leaving it unchanged in the argument list. This also applies to file
  expansion of an initial ‘~’ or ‘=’.

The documentation could probably be more explicit — it doesn't just print an
error, it also aborts the current command (and apparently the following ones; i
didn't even realise that).

You can disable it by setting either no_nomatch or null_glob (which both pass
the = pattern through as a literal string, somewhat surprisingly). If you don't
want one of those on permanently (a lot of people would recommend against it for
safety reasons), you can wrap it in an anonymous function or similar:

  () { setopt local_options no_nomatch; echo =123123 }

I don't think there's any way to disable it per-expansion in the vein of the (N)
glob qualifier.

dana

Re: `=' expansion causes script/subshell to exit, bug?

[Bart Schaefer]

On Thu, Sep 27, 2018 at 12:41 PM dana <dana@dana.is> wrote:
>
>   If a pattern for filename generation has no matches, print an error, instead
>   of leaving it unchanged in the argument list. This also applies to file
>   expansion of an initial ‘~’ or ‘=’.
>
> The documentation could probably be more explicit — it doesn't just print an
> error, it also aborts the current command (and apparently the following ones; i
> didn't even realise that).

This is more fully described in the "Errors" section of the manual (see
http://zsh.sourceforge.net/Doc/Release/Shell-Grammar.html#Errors
"Certain errors are treated as fatal by the shell: in an interactive
shell, they cause control to return to the command line, and in a
non-interactive shell they cause the shell to be aborted.")

In particular it lists:
* File generation errors where not caught by the option BAD_PATTERN
* File generation failures where not caused by NO_MATCH or similar options

I'm a little puzzled by the "not" in that second one because this
clearly does cause an abort on a non-match.  Maybe it means "where not
caught by"?  Of course the first one is also sort of backward, it
should probably say "NO_BAD_PATTERN" or make reference to "unsetopt
BAD_PATTERN".

> You can disable it by setting either no_nomatch or null_glob

null_glob has no effect on this for me.  I think you must have
accidentally had both nonomatch and nullglob set.

Re: `=' expansion causes script/subshell to exit, bug?

[dana]

On 27 Sep 2018, at 15:33, Bart Schaefer <schaefer@brasslantern.com> wrote:
>null_glob has no effect on this for me.  I think you must have
>accidentally had both nonomatch and nullglob set.

Oops, you're right, sorry.

The documentation does seem a little unclear, yeah. I might look at it later if
nobody beats me to it.

dana

Re: `=' expansion causes script/subshell to exit, bug?

[Mikael Magnusson]

On Thu, Sep 27, 2018 at 9:20 PM, Vasiliy Ivanov
<beelzebubbie.logs@gmail.com> wrote:
> Hello. Recently I've seen that line like
>
> [[ -x =somebinary ]] || cmd
>
> causes script to exit unexpectedly with message like «/path/to/script:$line: =somebinary not found»,
> instead of invoking || cmd and continue executing
>
> some simple tests:
>
> % ( [[ -x =123123 ]] || { print 'ohshi'; exit 2 } )
> zsh: 123123 not found <exit code 1>
>
> % ( b=123123; print =$b; print 'ohshi' )                                                  ↑
> zsh: 123123 not found
>
> Is it intended behaviour?
>
> % zsh --version
> zsh 5.6.2 (x86_64-pc-linux-gnu)

If you don't want to change any options, you can also use this
construct to avoid exiting without a subshell,

% { [[ -x =somebinary ]] } always { TRY_BLOCK_ERROR=0 } || echo hey
zsh: somebinary not found
hey

I also have this in my .zshrc
alias always_continue='always { TRY_BLOCK_ERROR=0 }'
so I can do just
% { [[ -x =somebinary ]] } always_continue || echo hey
zsh: somebinary not found
hey

-- 
Mikael Magnusson