From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <zsh-workers-return-33135-mason-zsh=primenet.com.au@zsh.org>
Received: (qmail 18818 invoked by alias); 9 Sep 2014 16:55:02 -0000
Mailing-List: contact zsh-workers-help@zsh.org; run by ezmlm
Precedence: bulk
X-No-Archive: yes
List-Id: Zsh Workers List <zsh-workers.zsh.org>
List-Post: <mailto:zsh-workers@zsh.org>
List-Help: <mailto:zsh-workers-help@zsh.org>
X-Seq: 33135
Received: (qmail 29332 invoked from network); 9 Sep 2014 16:55:00 -0000
X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on f.primenet.com.au
X-Spam-Level: 
X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_LOW
	autolearn=ham version=3.3.2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20120113;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to
         :content-type;
        bh=rTijbUE+z75tLJAbBey2KCOdUM3DYosWlSzpS8A/6BI=;
        b=UB+oQbrYiPr9j/I4z32LAGbACM4iqhq1oULTvO3OByPflHPGWverq7ttV56QjD4FZa
         D9lx9lSxXH1NqZUyK5KpnMCd0TSla8PmYwMYhXIOZuE+2tiNIkDEKxjlT4GorqnwfXI7
         xCrcCRaVH+BNDZRJluM79N2gTdw2UFTkxpNuwaj7FKhNcwCa0GjtEIH42qjSTqOd+mgl
         +62UwkN7x1xtDbtW4C6C38xNfXIm27lYnGQRJUlBgNC5v8mv9j6+qZBcrX0Al3IW9aNo
         kK4iEwfvgE8cKdPSvKtcOfeJQZuv8auYFCXltE3QgWUxXnOC5fMEi7G9ccXGzYQEIq1A
         ptYA==
MIME-Version: 1.0
X-Received: by 10.50.33.73 with SMTP id p9mr8424058igi.24.1410281695975; Tue,
 09 Sep 2014 09:54:55 -0700 (PDT)
In-Reply-To: <20140909174109.038d3b3e@pwslap01u.europe.root.pri>
References: <CAKjp4B7-EeMzsXWO6O7LjPCSEhurXsCC4f2K_-cjV-5vC_h1CQ@mail.gmail.com>
	<140903084448.ZM16438@torch.brasslantern.com>
	<CAKjp4B7Xbenzk9Ro6Kxz447csRmwwxJEhAronZJW+RZ5PuJr8w@mail.gmail.com>
	<20140909174109.038d3b3e@pwslap01u.europe.root.pri>
Date: Tue, 9 Sep 2014 12:54:55 -0400
Message-ID: <CAKjp4B5pFFjb0pTmGJzhg8qiYP00E=5dcRxcZcX1ON8m=rGa_A@mail.gmail.com>
Subject: Re: The ~ parameter expansion flag: bug or misunderstanding
From: Clint Hepner <clint.hepner@gmail.com>
To: zsh-workers@zsh.org
Content-Type: multipart/alternative; boundary=089e01538e5a86498d0502a4cb75

--089e01538e5a86498d0502a4cb75
Content-Type: text/plain; charset=UTF-8

Ah, that makes sense: ${(j.|.)~array} treats *all* | as part of the
pattern, but `${(~j.|.)array}` treats only those added as part of the join
operation. Thank you.

On Tue, Sep 9, 2014 at 12:41 PM, Peter Stephenson <p.stephenson@samsung.com>
wrote:

> On Tue, 09 Sep 2014 12:21:16 -0400
> Clint Hepner <clint.hepner@gmail.com> wrote:
> > Thanks. One thing I still can't quite wrap my mind around is a scenario
> > where
> >
> >     ${(j.|.)~array}
> >
> > and
> >
> >     ${~j.|.)array}
> >
> > would behave differently.
>
> It depends on the contents of array.  Here's the sort of scenario that
> caused the ~ inside the parentheses to be added.
>
> Supposing someone has helpfully created a file "a|b", and your array is
> a list of files in the current directory,
>
> array=(*)
>
> so it contains an alement "a|b".  zsh with its default settings usually
> handles that fine because it makes a point of not expanding the results
> of variable substitutions as patterns for exactly this reason.
>
> However, when you do ${(j.|.)~array} it looks like two alternatives, a
> or b, because the "|" in the value of $array is expanded.
>
> If you do ${(~j.|.)array}, on the other hand, the "a|b" is kept with the
> | as an ordinary character, so it still works.
>
> pws
>

--089e01538e5a86498d0502a4cb75--