[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Steven W. Orr
Subject: Re: Why can't I say "&>&3"? Bug or feature?
Date: Thu, 06 Dec 2012 12:30:35 -0500
User-agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0

On 12/6/2012 12:06 PM, DJ Mills wrote:
On Thu, Dec 6, 2012 at 6:11 AM, Dan Douglas <address@hidden> wrote:

I don't like &> to begin with. It makes the already cryptic redirection
that beginners struggle to understand even more confusing by adding a
pointless shortcut with a non-obvious meaning instead of just being
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,
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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]