4 ms·
> In many ways it does a better job of finding files by name than find does. Your du command is: du -a | grep -y "$1" | grep -y "$2" | awk '{print $2}' T
by tspiteri 16y ago
> In many ways it does a better job of finding files by name than find does.
Your du command is:
du -a | grep -y "$1" | grep -y "$2" | awk '{print $2}'
The find command I would use for the same effect is:
find -iregex ".*$1.*" -a -iregex ".*$2.*"
How does the du command do a better job than the find command?
- billswift 16y agoUnless find has been changed since the last time I tangled with it; you need to explicitly put the search path in first (which yours doesn't do), which since that is opposite the utilities I used more often, I kept forgetting to. Second, find seems to react weirdly to wildcards in search terms, I sometimes ended up rerunning it with slightly different search terms to be find the file I wanted. Maybe I just wasn't using find right, but several introductory linux books have also claimed it is hard to use. Before I found the du -a | grep idea, I was using one I read somewhere else of grepping a directory listing (made by ls -lR ~/ > dir) rather than use find.
- tspiteri 16y agoThe man page says that if path is omitted in find [path...] [expression] the current directory is used. I don't know if it's just that way for GNU find, or if it's standard Posix find behaviour. Regarding the wildcards in search statements, I usually just need to match a case-sensitive substring, so I use something like: find -name '*sub*' I don't know of any weird wildcard reactions, but that may be because I don't usually use complex searches or matches. One last thing, if you don't mind all the "./" prefixes, "find ." (or just "find") is just like "du -a" without the block counts.