Hacker News new | ask | show | jobs
by stouset 11 days ago
Or just use cat and spend your brainpower on interesting, useful, and/or worthwhile topics. It boggles my mind that anyone cares about this.
3 comments

If one needs brainpower to just use the redirection operator, it shows a likely lack of understanding of basic concepts in computing like processes and files. That should be concerning.
Probably, but knowing that redirection operators can be freely moved within normal arguments [EDIT: thank ButlerianJihad for pursuing me to make this more accurate] is useful.
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.
`2>&1` redirects FD2 to the current contents of FD1 (stdout), then `> /dev/null` redirects FD1 to /dev/null. That results in your errors going into stdout, and discarding regular output altogether:

    0: stdin  -> stdin  -> stdin
    1: stdout -> stdout -> /dev/null
    2: stderr -> stdout -> stdout
When you flip the order, `> /dev/null 2>&1` moves FD1 to /dev/null first, and then FD2 to the contents FD1 (/dev/null again), so you discard both errors and standard output:

    0: stdin  -> stdin     -> stdin
    1: stdout -> /dev/null -> /dev/null
    2: stderr -> stderr    -> /dev/null
In your example, `cat file` is unlikely to produce any errors, which is why you're not seeing a difference.
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.

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.
fish is not POSIX-compatible, and not Bourne-compatible, so I don't see how that really matters at all. I used the rc shell from plan9 for quite a while, and I wouldn't expect its syntax rules to match, either!
It's worth noting because the redirections and their syntax are nonetheless otherwise shared. I don't think POSIX compatibility for shells is that important tbf. The heart of a Unix shell has little to do with POSIX syntax.
And yet you've visited these comments and cared enough to type out one yourself.

I do agree that the performance cost of using "cat" is negligible, but sometimes it's instructive to learn techniques that improve efficiency. Personally, I write a lot of bash scripts and I tend to avoid using external programs when I can use built-ins e.g. "printf" instead of "echo", though avoiding "echo" is recommended anyway due to its lack of POSIX compliance.