exec n<&m versus exec n>&m -- based on Sobell's Linux book

The example is right in practice. The book's original explanation is an accurate description of what the POSIX standard says, but the POSIX-like shells I have handy (bash and dash, the only ones I believe are commonly seen on Linux) are not that picky.

The POSIX standard says the same thing as the book about input and output descriptors, and goes on to say this: for n<&word, "if the digits in word do not represent a file descriptor already open for input, a redirection error shall result". So if you want to be careful about POSIX compatibility, you should avoid this usage.

The bash documentation also says the same thing about <& and >&, but without the promise of an error. Which is good, because it doesn't actually give an error. Instead, empirically n<&m and n>&m appear to be interchangeable. The only difference between <& and >& is that if you leave off the fd number on the left, <& defaults to 0 (stdin) and >& to 1 (stdout).

For example, let's start a shell with fd 1 pointing at a file bar, then try out exactly the exec 4<&1 example, try to write to the resulting fd 4, and see if it works:

$ sh -c 'exec 4<&1; echo foo >&4' >bar; cat barfoo

It does, and this holds using either dash or bash (or bash --posix) for the shell.

Under the hood, this makes sense because <& and >& are almost certainly just calling dup2(), which doesn't care whether the fds are opened for reading or writing or appending or what.

[EDIT: Added reference to POSIX after discussion in comments.]

If stdout is a tty, then it can safely be cloned for reading or writing. If stdout is a file, then it may not work. I think the example should be 4>&1. I agree with Greg that you can both read and write the clone descriptor, but requesting a redirection with <& is supposed to be done with source descriptors that are readable, and expecting stdout to be readable doesn't make sense. (Although I admit I don't have a reference for this claim.)

An example may make it clearer. With this script:

#!/bin/bashexec 3<&0exec 4<&1read -p "Reading from fd 3: " <&3echo From fd 3: $REPLY >&2REPLY=read -p "Reading from fd 4: " <&4echo From fd 4: $REPLY >&2echo To fd 3 >&3echo To fd 4 >&4

I get the following output (the stuff after the : on "Reading from" lines is typed at the terminal):

$ ./5878384b.shReading from fd 3: fooFrom fd 3: fooReading from fd 4: barFrom fd 4: barTo fd 3To fd 4$ ./5878384b.sh < /dev/nullFrom fd 3:Reading from fd 4: fooFrom fd 4: foo./5878384b.sh: line 12: echo: write error: Bad file descriptorTo fd 4$ ./5878384b.sh > /dev/nullReading from fd 3: fooFrom fd 3: foo./5878384b.sh: line 9: read: read error: 0: Bad file descriptorFrom fd 4:To fd 3

Mind the difference between file descriptors and IO streams such as stderr and stdout.

The redirecting operators are just redirecting IO streams via different file descriptors (IO stream handling mechanisms); they do not do any copying or duplicating of IO streams (that's what tee(1) is for).

See: File Descriptor 101

Another test to show that n<&m and n>&m are interchangeable would be "to use either style of 'n<&-' or 'n>&-' for closing a file descriptor, even if it doesn't match the read/write mode that the file descriptor was opened with" (http://www.gnu.org/s/hello/manual/autoconf/File-Descriptors.html).