Hacker News Reader

Comment by kristjansson | Hacker News Reader

> 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.

View on HN

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".

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...

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'.

Reply on news.ycombinator.com