31–40 of 62 posts
Earlier quoted context omitted.
They are actually not “order-independent”, and their L-R parsing/processing is why constructs such as cat file > /dev/null 2>&1 work as intended.
funny enough, 2>&1 >/dev/null cat file appears to yield the same output. So i wonder where the not "order-independent" chimes in.
if this wanton abuse of cat(1) doesn't stop, we're on track to run out of PIDs by 2031! Just because Unix makes it cheap and easy to fork doesn't mean you have to! (who gives even a single shit, my god)
I like piping the output of cat and the mental image of one process feeding another. It's inconsequential, but it brings an epsilon of joy.
Program A might accept a file as the last positional arg. Program B might accept it as a named arg, where the name/flag could be anything from --input or -f or --file etc.
But a program will read from STDIN, which all good unix programs do, then piping cat into it works every time. I can write the cat foo.txt part before I even know what command I'm piping it into.
Earlier quoted context omitted.
funny enough, 2>&1 >/dev/null cat file appears to yield the same output. So i wonder where the not "order-independent" chimes in.
All of this depends on your specific shell and its parser. Fish doesn't let you put redirections at the beginning like that (though I wish it did), while GNU Bash does.
Earlier quoted context omitted.
They are actually not “order-independent”, and their L-R parsing/processing is why constructs such as cat file > /dev/null 2>&1 work as intended.
funny enough, 2>&1 >/dev/null cat file appears to yield the same output. So i wonder where the not "order-independent" chimes in.
0: stdin -> stdin -> stdin
1: stdout -> stdout -> /dev/null
2: stderr -> stdout -> stdout
0: stdin -> stdin -> stdin
1: stdout -> /dev/null -> /dev/null
2: stderr -> stderr -> /dev/null
The beauty of cat is that streams are the universal interface. Program A might accept a file as the last positional arg. Program B might accept it as a named arg, where the name/flag could be anything from --input or -f or --file etc. But a program will read from STDIN, which all good unix programs do, then piping cat into it works every time. I can write the cat foo.txt part before I even know what command I'm pipin…
I've probably lost 10ms * 1E5 of my life from the extra PID. But, probably would lose more in the context switch.
if this wanton abuse of cat(1) doesn't stop, we're on track to run out of PIDs by 2031! Just because Unix makes it cheap and easy to fork doesn't mean you have to! (who gives even a single shit, my god)
Earlier quoted context omitted.
funny enough, 2>&1 >/dev/null cat file appears to yield the same output. So i wonder where the not "order-independent" chimes in.
You're absolutely wrong! It does not yield the "same output", and here is why: if you cause your command to actually produce output on stderr (fd 2) it will appear as terminal output, because you have actually succeeded in "redirecting" stderr to wherever stdout (fd 1) was pointing initially.
if this wanton abuse of cat(1) doesn't stop, we're on track to run out of PIDs by 2031! Just because Unix makes it cheap and easy to fork doesn't mean you have to! (who gives even a single shit, my god)
Is this a dig at IPv6?
Edit: for context my home router is a TP Link and for some reason it has IPv6 disabled completely and I'm too scared to enable it.
The beauty of cat is that streams are the universal interface. Program A might accept a file as the last positional arg. Program B might accept it as a named arg, where the name/flag could be anything from --input or -f or --file etc. But a program will read from STDIN, which all good unix programs do, then piping cat into it works every time. I can write the cat foo.txt part before I even know what command I'm pipin…
"Oh no, it spawns another process!!" Again, nobody cares.