I'm playing around with file descriptors to better grok them and I'm failing to understand the following.
$ grep "..." 3>&1 1>/dev/null
1
12
13
123
321
3
The above does not show in the shell any of the matches, this is obviously happening because I'm redirecting to /dev/null. What I don't understand is why 3>&1 doesn't make it so that I still see the output, since I made a copy of it in fd 3.
What am I missing?
Your redirections do make FD 3 a copy of FD 1, so FD 3 will point to standard output and anything written to it will go to (by default) the TTY. You then redirect FD 1 to /dev/null, so anything written to FD 1 will be discarded. Because grep doesn't ever write to FD 3, nothing visible happens with it.
These happen in sequence: firstly a copy (dup2) of FD 1 is made to FD 3, so FD 3 henceforth points at what FD 1 currently points at, and secondly FD 1 is replaced by a pointer to /dev/null.
The end result is shown in the following diagram:
Standard error (in pink, FD 2) and FD 3 are to the TTY, and standard output is to /dev/null. FD 3 still points at the TTY because that's where FD 1 pointed when the copy was made. However, the grep command will not try to write anything to FD 3, so the copy never gets any use.
The "copying" is directional: after 3>&1 is processed, anything written to FD 3 will go to where FD 1 pointed at the time of processing. It doesn't "preserve" anything beyond that: if you subsequently redirect FD 1, anything written to it goes to the new place. What you've done is held on to the original destination of FD 1 in case you wanted to use it later. The only redirection that affects where grep's standard output ends up is the one 1>... that explicitly talks about where it goes.
If grep were to write to FD 3, it would appear in the terminal as expected. Because it only outputs to FD 1 normally, all of its actual output is being discarded.
We could make a grep outputting to FD 3 if we wanted:
( grep "..." >&3 )
That will take the regular output on FD 1 and point it at (the newly-created) FD 3 instead. This won't work if you run it directly, because FD 3 doesn't go anywhere, but we can incorporate it into something like this that makes use of it:
( grep "..." >&3 ) 3>&1 1>/dev/null
The command in parentheses outputs to FD 3. The redirections afterwards 1) point FD 3 (which now actually has content on it) at FD 1, and 2) then direct FD 1 away again (which has no effect). The end result is that you'll get the grep "..." output to standard output again, exactly where it would have been without all the fuss.
A practical use of this sort of redirection is something like
cmd 3>&1 1>&2 2>&3 3>&- | foo
which swaps FDs 1 and 2, using FD 3 as a temporary storage spot. It's also sometimes used for shell-script tricks, like faking process substitution in POSIX sh with ( cmd1 | ( cmd2 | ( main_command /dev/fd/3 /dev/fd/4 ) 4<&0 ) 3<&0 ). Otherwise, it's fairly rare that commands innately use any non-standard file descriptor by number (of course many open a file themselves and get one).
( grep x >&3 ) 3>&1 1>/dev/null
You're redirecting file-descriptor 3 to file-descriptor 1, and you're redirecting 1 to /dev/null. You're not making a copy of anything.
The normal way to copy a file-descriptor is with tee.
Also, I don't know what your context is, but 3 isn't a built-in file descriptor. Presumably you'd already set it up to point to something?
2>&1, the author says that "This one duplicates file descriptor 2 to be a copy of file descriptor 1".
2 instead of 3, it would print to the terminal and I wouldn't have sent anything either (not that I know of, I mean). There's a difference here that escapes me.
1is stdout and I'm duplicating it. Obviously I'm missing something, but I don't know what.grepis not printing anything to fd 3, so it doesn't matter if 3 points to the "screen" or elsewhere.