Splitting string to array removes pipe symbol

Splitting string to array removes pipe symbol

[Vincent Stemen]

Greetings.

First, let me take this opportunity to say thank you for such a
wonderful shell.  After switching over to Z shell I would never want
to go back to any of the previous shells.  Bash has served me well
over the years, but I am burning my bridge behind me.

I am working on a script that splits a string into an array in
preparation for execution with something like

  cmd="uncompress foobar | cpio -i --quiet --unconditional"
  cmd=($=cmd)

However, when the globsubst option is set, it removes the pipe '|'
symbol when it does the split.  Here is the trace output.

  +./t:62> cmd=uncompress foobar | cpio -i --quiet --unconditional
  +./t:63> cmd=( uncompress foobar cpio -i --quiet --unconditional )

If this is not a bug, then I must not fully understand the function of
GLOB_SUBST.  I have it set so that variables with wild cards, etc in
them will expand to a list of filenames.  Why would it remove the pipe
from the string in this case?

I am running zsh-4.1.0.dev5 on FreeBSD-5.1 in case it is relevant.

Regards,
Vincent

-- 
Vincent Stemen
Avoid the VeriSign/Network Solutions domain registration trap!
http://www.InetAddresses.net

Re: Splitting string to array removes pipe symbol

[Peter Stephenson]

Vincent Stemen wrote:
> However, when the globsubst option is set, it removes the pipe '|'
> symbol when it does the split.  Here is the trace output.
> 
>   +./t:62> cmd=uncompress foobar | cpio -i --quiet --unconditional
>   +./t:63> cmd=( uncompress foobar cpio -i --quiet --unconditional )

You have null_glob (or maybe csh_null_glob) set.  `|' is split to a
single bar.  Evaluation of the words takes place as if all the elements
of the array are arguments, which is different from evaluating as a
command.  (This is inevitable --- the only way of doing it differently
would be to parse the line again completely from scratch after the
glob_subst.)  In this case, the `|' is treated the same as (|),
i.e. either nothing or nothing, and removed since nothing matches it.
(You'd normally need the parentheses to stop it being evaluated as a
pipe, but it can't be in an argument list.)

You can fix this particular problem by quoting,
  cmd=("${(@)=cmd}")
but only because that cancels the effect of glob_subst, so that `|' is
just an ordinary character.  This may not be what you want.  It's
likely to be very difficult to force the shell both to split a line into
words *and* to parse it again as a full command line without joining it
up again.

Most people would probably come up with something using `eval'.  What you
should do depends why you need to split it at all.

-- 
Peter Stephenson <pws@csr.com>                  Software Engineer
CSR Ltd., Science Park, Milton Road,
Cambridge, CB4 0WH, UK                          Tel: +44 (0)1223 692070


**********************************************************************
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed. If you have received this email in error please notify
the system manager.

This footnote also confirms that this email message has been swept by
MIMEsweeper for the presence of computer viruses.

www.mimesweeper.com
**********************************************************************

Re: Splitting string to array removes pipe symbol

[Vincent Stemen]

On Tue, Dec 16, 2003 at 10:51:29AM +0000, Peter Stephenson wrote:
> Vincent Stemen wrote:
> > However, when the globsubst option is set, it removes the pipe '|'
> > symbol when it does the split.  Here is the trace output.
> > 
> >   +./t:62> cmd=uncompress foobar | cpio -i --quiet --unconditional
> >   +./t:63> cmd=( uncompress foobar cpio -i --quiet --unconditional )
> 
> You have null_glob (or maybe csh_null_glob) set.  `|' is split to a
> single bar.  Evaluation of the words takes place as if all the elements
> of the array are arguments, which is different from evaluating as a
> command.  (This is inevitable --- the only way of doing it differently
> would be to parse the line again completely from scratch after the
> glob_subst.)  In this case, the `|' is treated the same as (|),
> i.e. either nothing or nothing, and removed since nothing matches it.
> (You'd normally need the parentheses to stop it being evaluated as a
> pipe, but it can't be in an argument list.)
> 
> You can fix this particular problem by quoting,
>   cmd=("${(@)=cmd}")
> but only because that cancels the effect of glob_subst, so that `|' is
> just an ordinary character.  This may not be what you want.  It's
> likely to be very difficult to force the shell both to split a line into
> words *and* to parse it again as a full command line without joining it
> up again.
> 
> Most people would probably come up with something using `eval'.  What you
> should do depends why you need to split it at all.

I appreciate the quick reply.  You pinpointed exactly what the problem
was.  I did indeed have null_glob set.  I am learning to pay close
attention to the combination of options I have set when I get
unexpected behavior in Z shell scripts :-).

Putting quotes around the variable to be split did preserve the '|'
character.  However, I saw no difference in the result in this case
whether I used the (@) flag or did it with cmd=("${=cmd}").

The reason I was experimenting with splitting the line before
execution is because when I didn't, and ran "eval $cmd", I was getting
a null argument to eval.  Your reply pointed me in the right direction
to solve that mystery also :-).  I investigated further and found that
was also because of a null pattern expansion of the entire string.  My
final solution was to not split the string, use eval, and disable
glob_subst for the $cmd variable using "~~" (ie. eval ${~~cmd}).

Thank you very much for devoting your time to help.

- Vincent

-- 
Vincent Stemen
Avoid the VeriSign/Network Solutions domain registration trap!
http://www.InetAddresses.net