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

Question

In Mark Sobell, A Practical Guide to Linux Commands, Editors, and Commands, Second Edition, he writes (p. 432):

<& token duplicates the input file descriptor; > & Amp; duplicates the result of a file descriptor.

This seems to contradict another statement on the same page:

Use the following format to open or redirect file descriptor n as a duplicate of file descriptor m:

exec n <& m

and with an example also on the same page:

 # File descriptor 3 duplicates standard input # File descriptor 4 duplicates standard output exec 3<&0 4<&1 

If> & duplicates the output file descriptor, then we should not say

 exec 4>&1 

to duplicate standard output?

Answer 1

An example in practice. The book’s original explanation is an exact description of what the POSIX standard says, but I have POSIX-friendly shells ( bash and dash , the only ones that I think are common on Linux) are not picky.

The POSIX standard says the same thing as the book on input and output descriptors, and continues this: for n<&word , "if the numbers in the word do not represent a file descriptor that is already open for input, then a redirect error occurs." Therefore, if you want to be careful about POSIX compatibility, you should avoid this use.

The bash documentation also says the same thing about <& and >& , but without the promise of an error. This is good, because in fact it does not lead to an error. Instead, empirically, n<&m and n>&m seem to be interchangeable. The only difference between <& and >& is that if you leave the fd number on the left, <& will default to 0 (stdin) and >& to 1 (stdout).

For example, run the shell with fd 1, pointing to the bar file, then try the exec 4<&1 example for sure, try writing to the resulting fd 4 and see if it works:

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

This executes, and it executes using either dash or bash (or bash --posix ) for the shell.

Under the hood, this makes sense because <& and> & is almost certainly just called dup2 () , which doesn't care if fds are open for reading or writing or adding or what.

[ EDIT : added POSIX link after discussion in comments.]

Answer 2

If stdout is tty, then it can be safely 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 read and write a cloning descriptor, but a redirection request with <& should be done with the original descriptors that are readable, and expecting stdout to be readable does not make sense. (Although I acknowledge that I have no reference to this requirement.)

An example may make it clearer. With this script:

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

I get the following output (material after: on the line “Reading with” printed on the terminal):

 $ ./5878384b.sh Reading from fd 3: foo From fd 3: foo Reading from fd 4: bar From fd 4: bar To fd 3 To fd 4 $ ./5878384b.sh < /dev/null From fd 3: Reading from fd 4: foo From fd 4: foo ./5878384b.sh: line 12: echo: write error: Bad file descriptor To fd 4 $ ./5878384b.sh > /dev/null Reading from fd 3: foo From fd 3: foo ./5878384b.sh: line 9: read: read error: 0: Bad file descriptor From fd 4: To fd 3 

Answer 3

Note the difference between file descriptors and I / O streams such as stderr and stdout.

Redirection operators simply redirect I / O streams through various file descriptors (mechanisms for processing I / O streams); they do not perform any copying or duplication of input / output streams (for which te (1) is needed).

See: File descriptor 101

Another test showing that n <& m and n> & m are interchangeable will "use either the style of" n <& - "or" n> & - "to close the file descriptor, even if it does not match the read mode / the entry in which the file descriptor was opened using "(http://www.gnu.org/s/hello/manual/autoconf/File-Descriptors.html).