zsh-workers
 help / color / mirror / code / Atom feed
From: Bart Schaefer <schaefer@brasslantern.com>
To: zsh-workers@sunsite.dk,
	"Johann 'Myrkraverk' Oskarsson" <johann@myrkraverk.com>
Subject: Re: Keying arrays to names: is there an array of arrays?
Date: Mon, 29 May 2006 12:18:58 -0700	[thread overview]
Message-ID: <060529121858.ZM1916@torch.brasslantern.com> (raw)
In-Reply-To: <m3wtc5esxz.fsf@jin.myrkraverk.com>

[> zsh-workers]

On May 28,  9:32pm, Johann 'Myrkraverk' Oskarsson wrote:
}
} Bart Schaefer <schaefer@brasslantern.com> writes:
} 
} > That's actually incorrect.  The (z) option is already splitting the
} > value; you shouldn't need or want to split it again with (s: :).  If
} > the setting of IFS is preventing (z) from working properly, that's
} > probably a bug, but in any case the workaround is to make IFS local.
} 
} Well, all *I* know is that the s: : is needed -- at least without the
} local IFS solution.  If someone can (and is willing) to convince me
} that's a bug (I don't yet understand all the flags involved in these
} expansions) I can cook up some nice test case/bug report.

The (z) flag is supposed to split the line in the same way the shell
parser would split it.  IFS is only supposed to apply to "internal"
field splitting; in the case of zsh, that means sh_word_split, the
"read" builtin, etc. -- not the parser.

That is, given this test script:

    print -l foo bar
    print -l 'foo bar'
    x='foo bar'; print -l $x
    setopt sh_word_split; print -l $x

The result of

    source testscript
is
    foo
    bar
    foo bar
    foo bar
    foo
    bar

And the result of

    IFS="" source testscript
is
    foo
    bar
    foo bar
    foo bar
    foo bar

Note that parsing was unaffected, only expansion changed.

Assign those same strings to an array:

    script=( ${(f)"$(<testscript)"} )

The result of

    print -l ${(z)script}

should NOT depend on the value of IFS.  And in fact, it doesn't, in my
testing.

What may be a clue is that

    IFS=""; print -l "${(z)script}"

(quotes important) *IS* affected by the value of IFS, in that the array
elements are joined with nothing between them before the whole result is
split as if by the shell parser.  So I suspect that the reason you found
you needed (s: :) is because you had to reverse the effects of (j: :),
and you needed (j: :) in the first place because of the array joining
behavior when IFS is empty.


           reply	other threads:[~2006-05-29 19:19 UTC|newest]

Thread overview: expand[flat|nested]  mbox.gz  Atom feed
 [parent not found: <m3wtc5esxz.fsf@jin.myrkraverk.com>]

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=060529121858.ZM1916@torch.brasslantern.com \
    --to=schaefer@brasslantern.com \
    --cc=johann@myrkraverk.com \
    --cc=zsh-workers@sunsite.dk \
    /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).