Why can't I say "&>&3"? Bug or feature?
Hi folks, why is it that I can't say: exec 3>/dev/null echo foobar &>&3 # Error: "-bash: syntax error near unexpected token `&'" but the following works: echo foobar &>/dev/null echo foobar >&3 2>&3 I think the succinct notation "&>&N" where N is some numbered file descriptor should work also. Is this behavior a bug or feature? Cheers, Tim -- `°< C92A E44E CC19 58E2 FA35 4048 2217 3C6E 0338 83FC
Re: Why can't I say "&>&3"? Bug or feature?
On Thursday, December 06, 2012 11:48:09 AM Tim Friske wrote: > Hi folks, > > why is it that I can't say: > > exec 3>/dev/null > echo foobar &>&3 > # Error: "-bash: syntax error near unexpected token `&'" > > but the following works: > > echo foobar &>/dev/null > echo foobar >&3 2>&3 > > I think the succinct notation "&>&N" where N is some numbered file > descriptor should work also. Is this behavior a bug or feature? > > > Cheers, > Tim > -- > `°< > C92A E44E CC19 58E2 FA35 4048 2217 3C6E 0338 83FC dash and ksh interpret that syntax as "background the previous list element and apply >&3 to the next command", which I tend to think is most correct. mksh appears to do as you suggest. Bash fails to parse it. 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
Re: Why can't I say "&>&3"? Bug or feature?
On 12/6/12 5:48 AM, Tim Friske wrote: > Hi folks, > > why is it that I can't say: > > exec 3>/dev/null > echo foobar &>&3 > # Error: "-bash: syntax error near unexpected token `&'" Because the shorthand &> wasn't extended to arbitrary file descriptors. > but the following works: > > echo foobar &>/dev/null > echo foobar >&3 2>&3 > > I think the succinct notation "&>&N" where N is some numbered file > descriptor should work also. Is this behavior a bug or feature? It's simply a feature that was never implemented because there was little or no demand. 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: Why can't I say "&>&3"? Bug or feature?
On Thu, Dec 6, 2012 at 6:11 AM, Dan Douglas 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.
Re: Why can't I say "&>&3"? Bug or feature?
On 12/6/2012 12:06 PM, DJ Mills wrote: On Thu, Dec 6, 2012 at 6:11 AM, Dan Douglas 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
