are you saying that ordering counts, because I don't think it does.
>file = redirect stdout to file
2>&1 = redirect stderr to stdout which is being redirect to file
trying to state they = something seems like it would be confusing as they don't equal as much as just being re-routed.
Edit: I've never seen it described as TFA, but would have put money that I have done it in either order and worked without issue. i guess it's a good thing i'm not a gambler
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>&-.
Now the article tells me not to use them, but the justification [1] is a broken link. I assume [2] is the correct link, but the justification there is not convincing to me. It says other shells that don't implement them parse them differently, which is tautologically correct, and is also already the case for every other non-POSIX feature in bash and every other shell. So I'm not sure why these two operators should be treated differently.
>file = redirect stdout to file 2>&1 = redirect stderr to stdout which is being redirect to file
trying to state they = something seems like it would be confusing as they don't equal as much as just being re-routed.
Edit: I've never seen it described as TFA, but would have put money that I have done it in either order and worked without issue. i guess it's a good thing i'm not a gambler