3 ms·

Learned two things: `unbuffer` exists, and “unnecessary” cats are just fine :-)

by Rygian 2y ago

wrsh07 2y ago
I like unnecessary cat because it makes the rest of the pipe reusable across other commands Eg if I want to test out my greps on a static file and then switch to grepping based on a tail -f command
- chatmasta 2y ago
  Yep. I use unnecessary cats when I’m using the shell interactively, and especially when I’m building up some complex pipeline of commands by figuring out how to do each step before moving onto the next. Once I have the final command, if I’m moving it into a shell script, then _maybe_ I’ll switch to file redirection.
samatman 2y ago
I prefer the trivial cat, because the < redirect puts the source in the middle of the pipe. cat foo.txt | bar | blah > out.log vs. bar < foo.txt | blah > out.log It looks more like what it is. Also, with cat you can add another file or use a glob, that's come in handy more than once. Furthermore, it means the first command isn't special, if I decide I want something else as the first command I just add it. Pure... concatenation. heh. It's useful to know both ways, I suppose. But "don't use trivial cat" is just one of those self-perpetuating doctrines, there's no actual reason not to do things that way if you want.
- delamon 2y ago
  You can do it like this: < foo.txt bar | blah > out.log
  - samatman 2y ago
    Hey, TIL. I like that more, in a way, and less, in a way. The angle bracket is pointing off into nothing but throws `foo.txt` into `bar` anyway, so the control flow seems more messed up than in `bar < foo.txt`. On the other hand it's structurally a bit more useful, because I can insert a different first stage very easily. But I still can't add a filename or change it to a glob, so cat is still more flexible. So I'm going to stick to my trivial-catting ways, but thanks for the head's up.
Dan42 2y ago
grep has a --line-buffered option that does the job fine in most cases. Just set in your aliases grep='grep --line-buffered', that way you get the correct behavior when you tail logs piped to a sequence of greps, and you avoid the performance penalty in scripts.

Learned two things: `unbuffer` exists, and “unnecessary” cats are just fine :-)

by Rygian 2y ago

Learned two things: `unbuffer` exists, and “unnecessary” cats are just fine :-)

I like unnecessary cat because it makes the rest of the pipe reusable across other commands Eg if I want to test out my greps on a static file and then switch to grepping based on a tail -f command

chatmasta 2y ago
Yep. I use unnecessary cats when I’m using the shell interactively, and especially when I’m building up some complex pipeline of commands by figuring out how to do each step before moving onto the next. Once I have the final command, if I’m moving it into a shell script, then _maybe_ I’ll switch to file redirection.

samatman 2y ago

I prefer the trivial cat, because the < redirect puts the source in the middle of the pipe. cat foo.txt | bar | blah > out.log vs. bar < foo.txt | blah > out.log It looks more like what it is. Also, with cat you can add another file or use a glob, that's come in handy more than once. Furthermore, it means the first command isn't special, if I decide I want something else as the first command I just add it. Pure... concatenation. heh. It's useful to know both ways, I suppose. But "don't use trivial cat" is just one of those self-perpetuating doctrines, there's no actual reason not to do things that way if you want.

delamon 2y ago
You can do it like this: < foo.txt bar | blah > out.log
- samatman 2y ago
  Hey, TIL. I like that more, in a way, and less, in a way. The angle bracket is pointing off into nothing but throws `foo.txt` into `bar` anyway, so the control flow seems more messed up than in `bar < foo.txt`. On the other hand it's structurally a bit more useful, because I can insert a different first stage very easily. But I still can't add a filename or change it to a glob, so cat is still more flexible. So I'm going to stick to my trivial-catting ways, but thanks for the head's up.

Dan42 2y ago

grep has a --line-buffered option that does the job fine in most cases. Just set in your aliases grep='grep --line-buffered', that way you get the correct behavior when you tail logs piped to a sequence of greps, and you avoid the performance penalty in scripts.