On Mon, 29 Jan 2007, Christian Biere wrote:
> I'm a fan of this particular bashism:
> 
> make >& make.log 
  [...]
> There's only a minor clash with ksh's co-process feature, so make >& p
> (the whitespace is irrelevant) does not write to file "p" but rather
> the co-process respectively causes an error if there's none. I'd think
> this is neglible.

Your patch doesn't include changes to the man page, and I can't easily
tell whether quoting or variable expansion (as in {file="p"; make >&
$file}, or {make >& "p"}) will inhibit the special behaviour of an
unquoted 'p'.  I assume that {make >& ./p} will write to a file.

I have a preference for not adding such non-standard extensions in
a shell, because their mere existence encourages people to write
nonportable scripts.  This is much less of a consideration for ksh than
it is for /bin/sh.

--apb (Alan Barrett)