Re: ZSH expansion of an evaluated parameter containing a pipe character (and differences between 4.x and 5.x)

[Peter Stephenson <p.stephenson@xxxxxxxxxxx>]

On Thu, 09 Oct 2014 09:41:14 +0200
Enrico Maria Crisostomo <enrico.m.crisostomo@xxxxxxxxx> wrote:
> I’m trying to understand the rationale between a behavioural
> difference between ZSH 4.3.17 (current in latest Debian stable) and
> ZSH 5.0.2 (current in latest OS X).  I’m digging into the 'ZSH Shell
> Manual’ but I haven’t found the (exact) answer to my question yet.
> 
> The issue is the following.  What I’m doing is storing into a variable
> a command that will be executed later, the reason being the command
> depend on information only available at runtime.  I’ve detected a
> difference in behaviour between ZSH 4 and ZSH 5 when the
> aforementioned command contains a pipe.  For the sake of argument,
> let’s imagine the command is stored into `EXAMPLE_CMD` and is as
> simple as:
> 
>     EXAMPLE_CMD=“ls -al | grep text”
> 
> If I eval this variable using ZSH 5, the result is the expected:
> 
>     $ eval ${EXAMPLE_CMD}
> 
> that is:
> 
>   * `ls` is executed and passed `-al` as a parameter.
>   * Its output is piped through `grep`, that is passed `text` as a parameter.
> 
> When I do the same thing in ZSH 4, the behaviour is different and leads to this failure:
> 
>     # eval ${EXAMPLE_CMD}
>     zsh: no matches found: ls -al | grep text

I suspect you've got the GLOB_SUBST option set in the second case but
not the first --- if I set that in either version of the shell
(4.3.10-dev-1 is the oldest I had lying around) I get that error.
If I unset it I don't.

That's because in zsh "|" is a pattern match character as well as a
syntactical character.  In a normal command line you'd surround it with
parentheses to use it for pattern matching.  However, when it's being
substituted into the command line, so the line isn't being parsed, and
GLOB_SUBST is set, it's treated as a pattern character immediately.

GLOB_SUBST is usually used for compatibility with other shells with
different pattern matching behaviour.  If you set the option SH_GLOB as
well, which restricts pattern matching to standard sh-style patterns,
you should find the error goes away --- it does here in both versions of
the shell.

Basically, I think you need to decide if you want native zsh operation
--- both options off --- or sh-like operation --- both options on.
Arguably there are too many combinations, for historical reasons.

pws