zsh-users
 help / color / mirror / code / Atom feed
From: Enrico Maria Crisostomo <enrico.m.crisostomo@gmail.com>
To: zsh-users@zsh.org
Subject: ZSH expansion of an evaluated parameter containing a pipe character (and differences between 4.x and 5.x)
Date: Thu, 9 Oct 2014 09:41:14 +0200	[thread overview]
Message-ID: <etPan.54363c1a.5c7cdda7.f7ec@MacBook0.local> (raw)

Hi all,

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

However, if I quote `EXAMPLE_CMD` in either version of the shell, the result is the same:

    # eval “${EXAMPLE_CMD}”
    drwxr-xr-x  2 root root  4096 Oct  6 21:02 text

According to my observations, it seems this issue is limited to the interpretation of the pipe in the command, since I’ve found no other differences between the behaviours of the two shell versions in this case.

To me, it came quite as a surprise to discover that quoting worked, since I assumed that eval would receive 1 argument (the whole quoted string) and that its behaviour wouldn’t change.  Which leads me to think that either ZSH 4 is performing an expansion I’m not aware of affecting (at least) the meaning of `|`, or that this behaviour is buggy.

Now, the first question that I’m trying to answer is “Why expansion is done like that?”.  The second one that comes to mind is: what’s the rationale behind this change?  Is the behaviour of ZSH 4 considered buggy?

More generally: could you share your thoughts about the “proper”/“best”/“put your favourite adjective here" way to handle this case in ZSH?

Thank you very much for your insights.

Cheers,
--  
Enrico Maria Crisostomo


             reply	other threads:[~2014-10-09  7:46 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-10-09  7:41 Enrico Maria Crisostomo [this message]
2014-10-09 10:49 ` Peter Stephenson
2014-10-09 12:27   ` Enrico Maria Crisostomo

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=etPan.54363c1a.5c7cdda7.f7ec@MacBook0.local \
    --to=enrico.m.crisostomo@gmail.com \
    --cc=zsh-users@zsh.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/zsh/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).