3 ms·
I don't know what I was expecting, but one of my most-used command lines, "du -a | grep foo" is pretty uninformative.
by jff 13y ago
I don't know what I was expecting, but one of my most-used command lines, "du -a | grep foo" is pretty uninformative.
- evanspa 13y agoTried it. The explain read-out seemed reasonable. Care to elaborate how it wasn't informative?
- jff 13y agoThe explanation for "du" and its -a flag make it sound like I'm trying to find out how much disk space my files are using. Fine, that's the usual usage, but the point here is that it lists out every file under the current directory. The bigger problem is grep. We're told that grep prints lines matching a pattern, great. But then the explanation of the arguments makes it sound, to the uninitiated, like I'm giving "foo" as the filename, because the site doesn't include the actual grep syntax. It doesn't really explain what the command line is doing. It does seem to do a decent job of telling someone who's already fluent in shell usage the specific meaning of all options given. That's actually pretty important these days where any given GNU util will have flags for every single letter of the alphabet in both upper and lower case.
- ygra 13y agoThat's not really solvable in this case, though. All explainshell has are the man pages of the commands. It cannot know how they will interact with each other. It should be at least semi-possible in PowerShell (because you have output type information and parameter type information), but I hit a roadblock with ExplainPS a while ago and haven't had the time to resurrect it.
- wilcox 13y agoPerhaps you should go for find . / -name filename instead. Using du -a | grep filename works for sure, but it a bit of hack.
- w1ntermute 13y agoIf you're just trying to locate a file in the current directory, you should probably be using find.
- mturmon 13y agoJust for definiteness, the equivalent "find" idiom would be: % find . -path '*foo*' You need -path, not just -name, to match the whole name as du does.
- jff 13y agoI'll point out that the find command is 21 characters, while mine is only 17. Efficiency!
- mturmon 13y agoYes, you have a point (plus, those stars, they burn the eyes). But, your detractors will say yours is two processes and theirs is one. Efficiency!
- jff 13y agoThe kernel could start 100 processes in the time it takes me to type those extra four characters. We won't run out of processes. I did a test, finding .txt files in /usr/share, it took about .25 seconds longer with du and grep, which seems like less than it takes to type 4 more characters.
- girvo 13y agoHow long does it take you to type a character???
- jff 13y agoAssume I type 80 wpm A word is standardized as 5 keystrokes 80 wpm is therefore 400 keystrokes per minute. Divide by 60 to get about 6.6 keystrokes per second, or about 0.15 seconds per keystroke. Therefore it would take about 0.6 seconds to type the four extra characters, giving a net savings to use du+grep instead. And 80 wpm is probably a rather fast estimate; I'd guess that I type slower when I'm writing commands than when I'm entering English text.
- p9idf 13y agoI think I can one-up you. (while :; do cat ; sleep 2 ; done) <file
- JoshTriplett 13y agoHow is that not "tail -f file"?
- abraininavat 13y agoI'm curious why this is one of your most-used commands. If you want to know the sizes of all files matching 'foo', this is a horribly inefficient way of going about it.
- deelowe 13y ago"grep searches the named input FILEs (or standard input if no files are named..." Important bit being "or standard input." Also, what an odd one-liner. What's the use case for this that makes it such a common command: file names and sizes for all files matching a pattern beneath the current subdirectory (and all subdirectories and files within subdirectories matching that same pattern)? Genuinely curious.