Ordering counts! This, for me, was key to understanding the particular example above.
One of the challenges in the LPIC-1 study material I waaay back in 2008 was something like, how do you swap the stdout / stdin around? The solution required the use of a 3rd file descriptor, and an understanding that the order of ops was important.
Edit: let me embarrass myself by fucking this up, from my phone, without checking in a terminal...
run.sh 3>&1 1>&2 2>&3
So:
1. You point fd3 to "the thing that stdout is pointing at" (which keeps a safe copy of stdout during the juggling exercise)
2. Next you point fd1 at "the thing that stderr points to". So phase one is complete: stdout will now show the contents of stderr.
3. Finally you point fd2 at the copy of fd1's target. This completes the task, since stderr will now show the contents of stdout
We don't really care what happens to fd3. But if we did, we could fix that by directing it to /dev/null at the end. Again, showing how important the ordering is.
> We don't really care what happens to fd3. But if we did, we could fix that by directing it to /dev/null at the end. Again, showing how important the ordering is.
it's good practice to close extra FDs for children who are not expecting it. poorly designed applications may misbehave if provided with unexpected additional FDs. you shouldn't use /dev/null for this purpose, but instead actually close it with 3>&-.
One of the challenges in the LPIC-1 study material I waaay back in 2008 was something like, how do you swap the stdout / stdin around? The solution required the use of a 3rd file descriptor, and an understanding that the order of ops was important.
Edit: let me embarrass myself by fucking this up, from my phone, without checking in a terminal...
run.sh 3>&1 1>&2 2>&3
So:
1. You point fd3 to "the thing that stdout is pointing at" (which keeps a safe copy of stdout during the juggling exercise)
2. Next you point fd1 at "the thing that stderr points to". So phase one is complete: stdout will now show the contents of stderr.
3. Finally you point fd2 at the copy of fd1's target. This completes the task, since stderr will now show the contents of stdout
We don't really care what happens to fd3. But if we did, we could fix that by directing it to /dev/null at the end. Again, showing how important the ordering is.