Re: Why can't I say "&>&3"? Bug or feature?

[Steven W. Orr]

On 12/6/2012 12:06 PM, DJ Mills wrote:
> On Thu, Dec 6, 2012 at 6:11 AM, Dan Douglas <ormaaj@gmail.com> wrote:
>
> > I don't like &> to begin with. It makes the already cryptic redirection
> > syntax
> > that beginners struggle to understand even more confusing by adding a
> > pointless shortcut with a non-obvious meaning instead of just being
> > explicit.
> > If you don't understand the copy descriptor and all of a sudden see yet
> > another use for the & character to the left of a redirection operator,
> > you're
> > going to be even more confused.
> > --
> > Dan Douglas
> I completely agree with this. The '>&' syntax that's synonymous with '&>'
> is even worse for confusing beginners. There isn't really a point to adding
> this feature, imo, since it's easy to do it the regular way and it's more
> explicit/obvious what you mean.
>
> I also think that >&3 2>&1 would be what &>&3 actually does, not >&3 2>&3.
> Sure, they're the same in function, but it's not the same as >file 2>file.
> Again, this is part of that confusion thing. The copy descriptor is already
> complicated enough, there's no reason to make it more so.

Let's just keep our origins straight. There are a number of features in 
bash that came from the C shell. I'm not going to remind everyone why 
using csh is evil. That's been done to death. But the fact is that there 
are a number of csh features in bash that are very old. Examples are, 
use of csh meta history commands, as well as >& fn to mean the same as > 
fn 2>&1 (Bourne flavored long form)

Redirection should be done with an understanding of how things work. At 
the same time, redirection has a left to right associativity. That's why 
> fn 2>&1 is not the same as 2>&1 > fn

The bash man page specifically says that &> is preferred over >& (csh 
syntax) but that doesn't mean that &> should be preferred over Bourne 
flavored long form.

Steve Orr