45 ms·

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

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

ufo 3y ago
This works but it's so ugly :(
- kristjansson 3y ago
  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.
  - jltsiren 3y ago
    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.
    - MatmaRex 3y ago
      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
      - hk__2 3y ago
        > 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'.
n_plus_1_acc 3y ago
I agree that it's more elegant, but it requires you to remember the operator precendence of < vs |
- kristjansson 3y ago
  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-Commands https://www.gnu.org/software/bash/manual/bash.html#Simple-Co...
hk__2 3y ago
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".

ufo 3y ago

This works but it's so ugly :(

kristjansson 3y ago
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.
- jltsiren 3y ago
  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.
  - MatmaRex 3y ago
    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
    - hk__2 3y ago
      > 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'.

n_plus_1_acc 3y ago

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

kristjansson 3y ago
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-Commands https://www.gnu.org/software/bash/manual/bash.html#Simple-Co...

hk__2 3y ago

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