Zsh Mailing List Archive
Messages sorted by:
Re: preventing the leading space in process substitution
- X-seq: zsh-users 13212
- From: Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>
- To: zsh users mailing list <zsh-users@xxxxxxxxxx>
- Subject: Re: preventing the leading space in process substitution
- Date: Wed, 10 Sep 2008 09:05:54 -0700
- In-reply-to: <200809101510.m8AFAajX007203@xxxxxxxxxxxxxx>
- Mailing-list: contact zsh-users-help@xxxxxxxxxx; run by ezmlm
- References: <20080909144101.GA30693@xxxxxxxxxxxxxxxxxxxx> <200809101124.m8ABOlKI005063@xxxxxxxxxxxxxx> <080910074842.ZM19151@xxxxxxxxxxxxxxxxxxxxxx> <200809101510.m8AFAajX007203@xxxxxxxxxxxxxx>
On Sep 10, 4:10pm, Peter Stephenson wrote:
} Subject: Re: preventing the leading space in process substitution
} Bart Schaefer wrote:
} > On Sep 10, 12:24pm, Peter Stephenson wrote:
} > } For reasons buried in history that I don't understand, the <(...) is
} > } parsed as a single complete argument.
} > I think that's because the "<" is treated like a redirection operator.
} You mean we initially parse it the same way whether or not there's a "("
} coming up next or not, and later, when we've already finished the
} previous argument at that point, decide it's not a redirection after all?
Something like that, yes.
Returning briefly to the =(...) analogy: Note =(...) actually has to be
*written* as a separate word, except in an assignment, because otherwise
the parens are parsed as part of filename generation. So it's not as
badly inconsistent as I first thought to treat <(...) as a word also.
} But both ">file" and "> file" work, too, so presumably if we were able
} to change it so that "<(...)" and ">(...)" also worked in the middle of
} an argument it wouldn't create any new problems.
Well ... it would if anyone has previously written scripts etc. that
rely on the implicit splitting.
} We already need to look ahead for the "(" ... but probably not at
} the point where we first read the "<" and decide it's time to stop
} the current argument. At that point we'd have to look ahead two
} characters. That might be the real fly in the ointment.
As an aside, this is also one reason that it's hard to make zsh handle
typeset -a foo=(list)
the way that bash does.
Messages sorted by: