Mailing-List: contact zsh-workers-help@zsh.org; run by ezmlm
Precedence: bulk
Received-SPF: none (ns1.primenet.com.au: domain at brasslantern.com does not designate permitted sender hosts)
From: Bart Schaefer <schaefer@brasslantern.com>
Message-Id: <160810102836.ZM15324@torch.brasslantern.com>
Date: Wed, 10 Aug 2016 10:28:36 -0700
In-Reply-To: <20160809094013.01f0f5f8@pwslap01u.europe.root.pri>
Comments: In reply to Peter Stephenson <p.stephenson@samsung.com>
        "Re: [bug] shwordsplit not working on $@ when $# > 1" (Aug  9,  9:40am)
References: <20160808111626.GA19766@chaz.gmail.com> 
	<20160808192734.21923640@ntlworld.com> 
	<160808182124.ZM9355@torch.brasslantern.com> 
	<20160809094013.01f0f5f8@pwslap01u.europe.root.pri>
To: zsh-workers@zsh.org
Subject: Re: [bug] shwordsplit not working on $@ when $# > 1
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii

On Aug 9,  9:40am, Peter Stephenson wrote:
}
} On Mon, 08 Aug 2016 18:21:24 -0700
} Bart Schaefer <schaefer@brasslantern.com> wrote:
} > I *think* we can untangle this as follows, but then again I thought
} > I had untangled in in workers/29313, too.  This relies on the idea
} > that if we already have an array when nojoin, then we're not going
} > to split it again, which seems dubious somehow if there is explicit
} > use of the (s:-:) flag.
} 
} That was my first worry, looking at the change, but simple examples of
} this still work, so I can't see an obvious case where this isn't better
} than before.

It's better than before in that the two specific shwordsplit issues are
addressed.  However, I'm not sure that either of these cases is correct:

torch% x=(a:b "c d" ef)
torch% print -l ${(s.:.)x}
a
b c d ef
torch% print -l ${(@s.:.)x}
a:b
c d
ef

The first one agrees with zsh-3.0.8, so I guess it's no more wrong than
it ever was.  The second one used to work exactly like the first one,
and is the one that worries me the most.  I can fix that by testing
(nojoin % 2) instead of (!nojoin) but that seems like piling a hack on
top of a hack.

Then there's this weird edge case, where an empty $IFS acts like you
have specified the (@) flag when shwordsplit is set:

torch% IFS=
torch% setopt shwordsplit
torch% print -l ${(s.:.)x}
a:b
c d
ef