Latest LQ Deal: Complete CCNA, CCNP & Red Hat Certification Training Bundle
Go Back > Forums > Linux Forums > Linux - Server
User Name
Linux - Server This forum is for the discussion of Linux Software used in a server related context.


  Search this Thread
Old 12-28-2011, 10:44 AM   #1
LQ Newbie
Registered: Dec 2011
Location: Charlotte, NC
Distribution: Debian, Kbuntu, CentOS
Posts: 13
Blog Entries: 1

Rep: Reputation: 0
Don't Understand Duplicate File Descriptors in Bash

Hi all,

I am confused about duplicating file descriptors in Bash. Reading through Mark Sobell's "Practical Guide to Linux...", I ran across this example:
$ cat x y 1> hold 2>&1
$ cat hold
cat: x: No such file or directory
This is y.
Both the error and the contents of 'y' go to the file 'hold'. It appears to be effectively equivalent to this:
$ cat x y &> hold
$ cat hold
(same output as above)

But I am not sure what the point is. The first example seems like going the long way around the barn to me (and confusing to read). It's ok to take the long way, as long as there is a purpose to it. I'm sure there is a purpose, but I just don't quite get it. Is there any particular advantage to using the first method over the second one? Or maybe one works better than the other in certain scenarios?

Sobell labels the first one as a duplicate descriptor, and the second is an example of combining stdout and stderr. Combining, duplicating... making my head hurt.
Old 12-28-2011, 01:22 PM   #2
Senior Member
Registered: Aug 2009
Distribution: CentOS
Posts: 2,959

Rep: Reputation: 1268Reputation: 1268Reputation: 1268Reputation: 1268Reputation: 1268Reputation: 1268Reputation: 1268Reputation: 1268Reputation: 1268
Those are illustrations of two similar actions, and for this simple case the result is exactly the same. As is common for trivial examples, there's no advantage for doing it the "long" way (though the "&>" syntax is, I believe, a somewhat newer addition to the shell, so you'll find a lot of older scripts using the "duplicate" syntax). Think of the combining operation ("&>") as a shorthand notation for a common, simple case that does not extend to more complex situations or file descriptors other than stdout and stderr.
Old 12-28-2011, 07:50 PM   #3
David the H.
Bash Guru
Registered: Jun 2004
Location: Osaka, Japan
Distribution: Debian sid + kde 3.5 & 4.4
Posts: 6,823

Rep: Reputation: 1957Reputation: 1957Reputation: 1957Reputation: 1957Reputation: 1957Reputation: 1957Reputation: 1957Reputation: 1957Reputation: 1957Reputation: 1957Reputation: 1957
The key difference is very simply that the first pattern is fully portable, while the second one is a bash-specific shortcut for it. If you aren't using bash, you can't do the latter (unless some other shell has also adopted it that I don't know about).

File descriptors are certainly a hard thing to get your head around, and I'm still not all that proficient myself. But there are two confusing points, both related, that I finally understood that helped to clarify how it works.

1) The program sends its two kinds of output to file descriptors 1 and 2, and all the redirections you do for fd1 and fd2 are for these these two original outputs.

So this:
command 1>&2 2>file
...means that the command's stdout is redirected to the shell's stderr output, and the command's stderr is redirected to the file. It does NOT mean that you're sending fd1 into fd2, and then fd2 into the file, as if they were chained together. The second point is also involved here...

2) "&2" does NOT mean "stderr". It means "to the place fd2 is currently pointing". & references the target of the file descriptor, not the descriptor itself.

So taking these two:

command 2>&1 1>file
command 1>file 2>&1
The first one means, "send the command's stderr to the current target of fd1, which is the screen, and the command's stdout to the file".

The second line says "send the command's stdout to the file, and send the command's stderr to the current target of fd1, which has just been redefined as the file". Therefore both outputs go into the file.

I hope that helps clear it up a bit.

Last edited by David the H.; 12-28-2011 at 07:56 PM. Reason: wording fix
Old 12-29-2011, 12:27 AM   #4
LQ Newbie
Registered: Dec 2011
Location: Charlotte, NC
Distribution: Debian, Kbuntu, CentOS
Posts: 13
Blog Entries: 1

Original Poster
Rep: Reputation: 0
Thanks guys! I think I understand a little better now. I won't swear to it, but I believe so. @David the H: I did play with this in all three forms you presented here, using one file and one erroneous filename. Just reading made my head hurt more than before, but after tinkering a bit, I feel better about it now.



Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off

Similar Threads
Thread Thread Starter Forum Replies Last Post
CSV file - Duplicate records need merging | BASH? lmedland Programming 21 12-10-2010 06:01 AM
Please help me understand some SCSI descriptors crazydown Linux - Software 1 03-09-2010 12:48 PM
Don't quite understand The File Hierarchical System in Linux? jacatone Linux - Newbie 3 08-07-2005 10:55 PM
BASH scripting: confused about redirection & file descriptors funkymunky Programming 1 06-07-2004 08:47 AM

All times are GMT -5. The time now is 02:56 PM.

Main Menu
Write for LQ is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration