Alan Barrett wrote:
> 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'.

"p" or using a variable does not suppress the special behaviour for >&p, the
same applies to using digits. ksh does not differ between >&"3" and >&3. csh
apparently doesn't support the >&[file descriptor] redirection, but bash
behaves the same.

> I assume that {make >& ./p} will write to a file.

Yes, it does.
 
> I have a preference for not adding such non-standard extensions in
> a shell, because their mere existence encourages people to write
> nonportable scripts.

You have a point there but I find this feature only relevant for interactive
use. I don't think I ever used in scripts. The same could be said, for example,
about GCC extensions. They can be used to improve things but they can very well
be used to achieve the opposite. I don't see why the penalty should go to wrong
people though. I thought we sell rope?

-- 
Christian