Re: |& in bash?
On 1/18/13 4:10 PM, Dan Douglas wrote: > In scripts it breaks POSIX, conflicts with the coproc operator in kshes, and > applies the redirections in an unintuitive order since the same operator > redirects stdout first, then applies the stderr redirect after other > redirections. It isn't very common to dump multiple streams into one pipe. I > suggest avoiding |&. It doesn't `break' Posix. Posix doesn't say anything about it, so it's simply undefined. It's syntactic sugar. A parser macro, if you will. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
Re: |& in bash?
On Saturday, January 19, 2013 02:47:38 PM Chet Ramey wrote: > On 1/18/13 4:10 PM, Dan Douglas wrote: > > > In scripts it breaks POSIX, conflicts with the coproc operator in kshes, > > applies the redirections in an unintuitive order since the same operator > > redirects stdout first, then applies the stderr redirect after other > > redirections. It isn't very common to dump multiple streams into one pipe. > > I suggest avoiding |&. > > It doesn't `break' Posix. Posix doesn't say anything about it, so it's > simply undefined. Not necessarily, but I know what you meant. An operator consisting of a mash-up of syntax that has another meaning elsewhere isn't necessarily well-formed. Perhaps somebody did find that it's ok. e.g. the `;|' zsh/mksh case-delimiter is a similar-looking extension. Syntax in which the only way to write certain compatibility wrappers is to shield it from parsers through an eval is the least desirable way to extend a language IMO. > It's syntactic sugar. A parser macro, if you will. That makes sense. -- Dan Douglas
