Hacker News Reader

Comment by hk__2 | Hacker News Reader

> And if you really really want to keep it separate, just do "< access.log head -500 etc etc etc" (no I didn't forget a pipe. And yes the "< inputfile" works even if it's in front of what you're calling).

Or just use `cat` and let the pipe separate the different steps. "< access.log head" is nice but it breaks this representation where each step is piped into the next one. Sure, once you’re done fiddling you can rewrite the thing to remove the "cat", but when you are constructing the thing I find it clearer to use cat.

View on HN

> Sure, once you’re done fiddling you can rewrite the thing to remove the "cat"

Or just… don’t?

Sure. Don't. Or do. Whatever you prefer.

> it breaks this representation where each step is piped into the next one

No it doesn't?

  < access.log head -n 500 | grep mail | perl -e …

is completely valid, and reads right-to-left as well as the cat version. IMO using stdin is preferable to either solution in TFA.

This works but it's so ugly :(

I think it's beautiful? Reads left-to-right, has nice symmetry if you pipe to an output file like:

    < infile some_cmd > outfile

and real clarifies what's a shell command, what's a redirection, etc.

It would make more sense like:

    infile > some_cmd > outfile

Then the arrow would be pointing in the right direction. But then it would be unclear whether "infile" is a file or a command. Which is why people use:

    cat infile | some_cmd > outfile

You can now interpret "cat" as a keyword that specifies that "infile" is a file.

It is more pleasant to the eye if you remove the spaces:

    <infile some_cmd >outfile

Just like you wouldn't add spaces in the middle of '2>&1' when redirecting stderr to stdout:

    <infile some_cmd >outfile 2>&1

> Just like you wouldn't add spaces in the middle of '2>&1' when redirecting stderr to stdout:

Mostly because if you do it doesn’t work: '2 >&1' is not the same as '2> &1' (invalid syntax) which is not the same as '2>& 1', which …is the same as '2>&1'.

I agree that it's more elegant, but it requires you to remember the operator precendence of < vs |

It's not really a precedence relation as much as it's part of shell syntax. There are separators[0], and anything sequence of tokens between a separator is a command[1]. A command decomposes further, of course, but the only thing the programmer needs to know here is that separators are a different kind of thing than commands.

[0]: newline, ‘||’, ‘&&’, ‘&’, ‘;’, ‘;;’, ‘;&’, ‘;;&’, ‘|’, ‘|&’, ‘(’, or ‘)’.

[1]: https://www.gnu.org/software/bash/manual/bash.html#Simple-Co...

I’m not talking about valid syntax but about visual representation. My eyes don’t scan "<access.log head" the same as "cat access.log | head".

Reply on news.ycombinator.com