From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2285 invoked from network); 12 Jul 2000 10:47:47 -0000 Received: from sunsite.auc.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 12 Jul 2000 10:47:47 -0000 Received: (qmail 6980 invoked by alias); 12 Jul 2000 10:47:33 -0000 Mailing-List: contact zsh-workers-help@sunsite.auc.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 12232 Received: (qmail 6973 invoked from network); 12 Jul 2000 10:47:29 -0000 Date: Wed, 12 Jul 2000 12:47:27 +0200 (MET DST) Message-Id: <200007121047.MAA21893@beta.informatik.hu-berlin.de> From: Sven Wischnowsky To: zsh-workers@sunsite.auc.dk In-reply-to: Peter Stephenson's message of Wed, 12 Jul 2000 11:40:00 +0100 Subject: Re: Bug in ${(z)...} lexing, or what? Peter Stephenson wrote: > Sven wrote: > > There is still something fishy, though. A string like `ls (#i)foo' is > > broken into `ls' and `(#i)foo', but `[[ (#i)foo ]]' is broken into > > `[[', `(', `#i', `)', ... I haven't found out where and why this > > happens yet. > > I can partly answer that. There's a context dependency in conditions, > because a `(' may introduce the start of a pattern, as here, or it may > introduce the start of a group. Luckily, the former only happens when we > are expecting an argument to a test (you can't have patterns on the left of > an `=' or `!=', otherwise the issue would have been unresolvable) and the > latter when we are expecting a complete test, so we can check. In your > example, `(' should indeed be a single token introducing a group, so the > parsing is correct. I don't know exactly what happens on the right of an > `=', but it's possible that in that case, too, the `(' is lexed before we > decide and the string put together later, but it may also be normal. I should have used this example: % a='[[ a = (#i)foo ]]' % print -l ${(z)a} [[ a = ( #i ) foo ]] Bye Sven -- Sven Wischnowsky wischnow@informatik.hu-berlin.de