3 ms·
"grep -c" is great if you know it. This is a tough criticism, since "wc -l" is great if you know it too. And that, in the rush version, you need to use .lines
by thwarted 16y ago
"grep -c" is great if you know it.
This is a tough criticism, since "wc -l" is great if you know it too. And that, in the rush version, you need to use .lines on the result of .search() in order to get something you can call .size on to get the exact result you want (because it seems you can't just call .size on the result of .search(), I suspect that would just return a count of files where the string appears at least once).
In that vein, with a pipeline, you can look at each bit independently and reason about it. You can't reason about what .size returns (lines or bytes or whatever) without looking at what is immediately to the left of it (and then you have to know that .lines returns an array and that .size is returning the length of that array). And you have to know that whatever .lines returns actually has a .size method. wc -l always counts lines, no matter what its context is, because it's only ever dealing with text based input, never more complexly structured data like objects or arrays. This may or may not be what you want, but it does lend itself to wider (re)usability.
- DavidSJ 16y agoI think you've mistaken my argument as being against pipelines, but in fact I was arguing in favor of pipelines and against one-off tricks like "grep -c". Yes, "wc -l" needs to be memorized, but once, for everything you ever wish to count, as opposed to once for every command. In this respect, "grep -c" has the same problem as you pointed out concerning "lines".