When you redirect something to &number
, you are not opening a new file at all; you're reusing an already open file along with whatever mode it was opened.
The numbers refer to "open file" handles (file descriptors). So there is no technical difference between how >&
and >>&
(and indeed <&
) would work – they all just mean "clone the existing file descriptor using dup()".
That is, 2>&1
indicates that file descriptor #1 (which you previously opened for appending using >>logfile
) is cloned into number #2. And yes, 2<&1
works identically.
Side technical note: Appending vs truncating is not an explicit action done by the shell; it's actually a mode the shell specifies when opening the file, and the rest is performed by the OS itself. For example, when you use >
the shell doesn't manually erase the old contents, it just adds O_TRUNC when calling open(). Therefore, when open() isn't called at all, the previous mode remains unchanged.
9Welcome to Super User and congrats on an interesting first question! – gronostaj – 2019-05-06T11:04:02.130
14The tokens aren't split up the way you think they are. That is, it's not "
>
for redirect to file" and "&1
for which file to redirect to", it's ">&
for redirect to file descriptor (which is not the same thing as a file)" and "1
for which descriptor to redirect to". So it's a completely different operation, and you shouldn't a priori expect to be able to transfer any intuition from>
or>>
to>&
. (This is just a first approximation. In the second approximation, there are some implementation details shared between the three operators, so you can transfer some knowledge...) – Daniel Wagner – 2019-05-06T17:49:27.6238@DanielWagner Please don't answer in comments. – David Richerby – 2019-05-07T15:38:48.010