Re: preventing the leading space in process substitution

[Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>]

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.

Yes.

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.