4 ms·

- fd: an improved find Depends on what you need to do, at least without constructing a pipeline like it's 1990 (modern..), probably on your age, and how much yo

- fd: an improved find Depends on what you need to do, at least without constructing a pipeline like it's 1990 (modern..), probably on your age, and how much you suck at typing. I have it installed as well, but most of the time still use find and not just in scripts which hopefully is a no-brainer. Some rather weird decisions went into that iteration, or call it taste if you prefer. Even the name is a joke honestly. But what in and out of Rust isn't. Re-inventing the wheel, ok. But then why not, err, also improve on it? - hexyl: a better xxd Like what?! - ripgrep: a cornerstone of my workflow, an improved grep No, it's a by default recursive grep which grep emphatically isn't, wasn't and never aimed to be. It has many, many more features, is bigger, newer, shinier and (yes) a bit slower. But that's ok, I use it too where it makes sense, as usual. An improved silversearcher, maybe that! I'm barely using anything of the mentioned. But then I hate colors, and when I want to see nice pictures I'm off to the movies. At least your definition of modern is actually funny.

llimllib 2y ago
For me, fd is as better than find as ripgrep is to grep The main benefits are: - it skips ignored and hidden files by default - it uses modern regular expressions - it has a more sane UI (`find . -iname '*.txt'` -> `fd -g '*.txt'`) I do use it in scripts as long as I know they're going to run in a context where it's available, ex: https://github.com/llimllib/personal_code/blob/c3d33b4d95f89ad19974a8eed65eac16906572a2/homedir/sync.bash#L39 https://github.com/llimllib/personal_code/blob/c3d33b4d95f89...
burntsushi 2y ago
> It has many, many more features, is bigger, newer, shinier and (yes) a bit slower. Can you show a common case where ripgrep is meaningfully slower than grep? Here are a few common cases where ripgrep is meaningfully faster than GNU grep 3.11 on Linux. The setup: $ cd /dev/shm $ curl -LO 'https://burntsushi.net/stuff/OpenSubtitles2018.raw.sample.en.gz' $ gunzip OpenSubtitles2018.raw.sample.en.gz A simple case: $ time rg -c 'Sherlock Holmes' OpenSubtitles2018.raw.sample.en 502 real 0.102 user 0.056 sys 0.046 maxmem 903 MB faults 0 $ time LC_ALL=C grep -c 'Sherlock Holmes' OpenSubtitles2018.raw.sample.en 502 real 0.378 user 0.255 sys 0.122 maxmem 21 MB faults 0 A case with multiple substrings: $ time rg -c -e 'Sherlock Holmes' -e 'John Watson' -e 'Irene Adler' -e 'Professor Moriarty' OpenSubtitles2018.raw.sample.en 628 real 0.128 user 0.077 sys 0.050 maxmem 903 MB faults 0 $ time LC_ALL=C grep -c -e 'Sherlock Holmes' -e 'John Watson' -e 'Irene Adler' -e 'Professor Moriarty' OpenSubtitles2018.raw.sample.en 628 real 0.580 user 0.516 sys 0.063 maxmem 21 MB faults 0 You can run the `rg` commands with `--no-mmap` to get slightly slower but roughly similar times but using standard `read` syscalls instead of file-backed memory maps. I chose these cases because they represent common and simple queries. And, specifically, it's searching a single text file. There isn't anything involving parallelism or skipping files or recursive search or whatever.

llimllib 2y ago

For me, fd is as better than find as ripgrep is to grep The main benefits are: - it skips ignored and hidden files by default - it uses modern regular expressions - it has a more sane UI (`find . -iname '*.txt'` -> `fd -g '*.txt'`) I do use it in scripts as long as I know they're going to run in a context where it's available, ex: https://github.com/llimllib/personal_code/blob/c3d33b4d95f89ad19974a8eed65eac16906572a2/homedir/sync.bash#L39 https://github.com/llimllib/personal_code/blob/c3d33b4d95f89...

burntsushi 2y ago

> It has many, many more features, is bigger, newer, shinier and (yes) a bit slower. Can you show a common case where ripgrep is meaningfully slower than grep? Here are a few common cases where ripgrep is meaningfully faster than GNU grep 3.11 on Linux. The setup: $ cd /dev/shm $ curl -LO 'https://burntsushi.net/stuff/OpenSubtitles2018.raw.sample.en.gz' $ gunzip OpenSubtitles2018.raw.sample.en.gz A simple case: $ time rg -c 'Sherlock Holmes' OpenSubtitles2018.raw.sample.en 502 real 0.102 user 0.056 sys 0.046 maxmem 903 MB faults 0 $ time LC_ALL=C grep -c 'Sherlock Holmes' OpenSubtitles2018.raw.sample.en 502 real 0.378 user 0.255 sys 0.122 maxmem 21 MB faults 0 A case with multiple substrings: $ time rg -c -e 'Sherlock Holmes' -e 'John Watson' -e 'Irene Adler' -e 'Professor Moriarty' OpenSubtitles2018.raw.sample.en 628 real 0.128 user 0.077 sys 0.050 maxmem 903 MB faults 0 $ time LC_ALL=C grep -c -e 'Sherlock Holmes' -e 'John Watson' -e 'Irene Adler' -e 'Professor Moriarty' OpenSubtitles2018.raw.sample.en 628 real 0.580 user 0.516 sys 0.063 maxmem 21 MB faults 0 You can run the `rg` commands with `--no-mmap` to get slightly slower but roughly similar times but using standard `read` syscalls instead of file-backed memory maps. I chose these cases because they represent common and simple queries. And, specifically, it's searching a single text file. There isn't anything involving parallelism or skipping files or recursive search or whatever.