3 ms·
> 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 ev
by hk__2 3y ago
> 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.
- stouset 3y ago> Sure, once you’re done fiddling you can rewrite the thing to remove the "cat" Or just… don’t?
- margalabargala 3y agoSure. Don't. Or do. Whatever you prefer.
- kristjansson 3y ago> 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 agoThis works but it's so ugly :(
- kristjansson 3y agoI 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 agoIt 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 agoIt 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 agoI agree that it's more elegant, but it requires you to remember the operator precendence of < vs |
- kristjansson 3y agoIt'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 agoI’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".