Bash: Redirecting file descriptors

Question

I am hoping someone can explain a phenomenon. As the title indicates I am learning about redirection of file descriptors. Along the way I have come across a question surrounding the use of the redirect symbol, specifically when setting permanent redirection. I have noticed that in certain cases it does not seem to matter whether I use < or >. For example, working with the following script:

#!/bin/bash

#Setting file descriptor 3 to redirect  to STDIN
exec 3<&0

#Setting STDIN to read from input file
exec 0<inputFile


while read var
do
    echo "$var"

done

#Setting STDIN to read from file descriptor 3 which is redirected to the default STDIN
exec 0<&3

read -p "Enter a word:" word

echo "$word"

To my astonishment it does not seem to matter if I use > or < in the statements exec 3<&0 or exec 0<&3. In either of these statements it seems that if I swap out the redirect symbols, I still get the exact same result. It seems obvious to me that making the same types of changes to the line:

exec 0<inputFile

vs.

exec 0>inputFile

does not produce the same results, because redirecting STDIN to a file is not the same thing as redirecting a file to STDIN.

So my questions are:

1. < vs >:

   # Why aren't there any differences between these two statements?
   exec 3<&0
   exec 3>&0
   

2. 3<&0 vs 0<&3:

   # Why is there a difference between these two statements?
   exec 3<&0
   exec 0<&3
   

This type of redirection is hard enough for me to wrap my head around and keep straight without these types inconsistencies. Any explanation(s) will be greatly appreciated.

Answer 1

When duplicating file descriptors, it doesn't matter, dup2 is called, no matter if you use < or >.

The same occurs when closing file descriptors. You can use n>&- or n<&-.

---

However why then is 0<&3 not the same thing as 3<&0?

That's explained in the dup2 spec I linked:

int dup2(int fildes, int fildes2);

The dup2() function shall fail if:

[EBADF]

The fildes argument is not a valid open file descriptor or the argument fildes2 is negative or greater than or equal to {OPEN_MAX}.

In the case of exec 0<&3, Bash calls dup2(3,0) and indeed receives EBADF error (since we're in the case fildes=3 which is not a valid open file descriptor at that time). You can easily check that with strace:

$ strace -e dup2 bash -c 'exec 0>&3'
dup2(3, 0)                              = -1 EBADF (Bad file descriptor)
bash: 3: Bad file descriptor
dup2(10, 0)                             = 0
+++ exited with 1 +++