9 ms·

Even though of course nothing beats the power of a set of standardized and ubiquitous tools that you can always count on whenever you find yourself on a new mac

Even though of course nothing beats the power of a set of standardized and ubiquitous tools that you can always count on whenever you find yourself on a new machine, I must admit that I'm favorably inclined toward this trend (or what I perceive as one) of rewriting classic CLI tools with sometimes radical performance improvement promises, but most importantly (for me at least) better UIs: `grep` has always been acceptable for me, but I prefer `ag` these days, and I recently discovered `fd`, which seems like it will replace `find`, as I could never remember its weird syntax, even for the most basic cases.

crowbahr 7y ago
Thank you. Find is so complex and looking at fd is a revelation here. Now I feel like all my hard earned cli-fu is a lie.
- michaelcampbell 7y ago
  Care to share a link? Using fd as a utility name for an os that already uses the word fd as file descriptor is maddeningly hard to find
  - thunderbong 7y ago
    I'm assuming it's this - https://github.com/sharkdp/fd https://github.com/sharkdp/fd
  - deleted 7y ago
    [deleted]
  - h1d 7y ago
    It's the first result for a maddeningly simple search of "cli fd".
- hermitdev 7y ago
  I remember posting a bug to WSL about supposedly incorrect behavior with find, only to realize that I had incorrect syntax. I forgot to include the escape on the terminating semicolon (also, conveniently never shown the man pages), or maybe it was the enclosing parens around an or for name pattern matching. Anyways, Id been away from *nix for a few years at the time, so I was a bit rusty and soon felt like a moron and closed the bug once I realized my error.
- enriquto 7y ago
  > Find is so complex and looking at fd is a revelation here. > Now I feel like all my hard earned cli-fu is a lie. fd is also a lie. If you want a decent interface to find just use "find | grep ..."
GolDDranks 7y ago
Have you tried RipGrep (rg)? I think it's the fastest one these days.
rlue 7y ago
Try rg (ripgrep) over ag: https://github.com/BurntSushi/ripgrep https://github.com/BurntSushi/ripgrep
- jdc0589 7y ago
  ripgrep is incredible
- krick 7y ago
  Never managed to switch to ripgrep over ag. Performance difference is not that much of a dealbreaker in practice, and rg is not totally backwards-compatible to ag. I don't exactly remember, what was the problem. I guess it has this annoying practice to ignore everything that's in .gitignore, while for ag I could set up an additional .agignore per-project.
  - OJFord 7y ago
    Rg similarly supports it's own ignore file, and optionally disabling the default of respecting .gitignore.
  - burntsushi 7y ago
    For ripgrep, if you want to use PCRE2 regexes (assuming that's what you meant by backwards compatible), then the -P flag will do that. Otherwise, ripgrep's support for .gitignore should be substantially better than what's in ag. You can use .rgignore just like .agignore. Both ripgrep and ag also support .ignore. These can override whatever is in your .gitignore. See the guide for more details: https://github.com/BurntSushi/ripgrep/blob/master/GUIDE.md#automatic-filtering https://github.com/BurntSushi/ripgrep/blob/master/GUIDE.md#a... > Performance difference is not that much of a dealbreaker in practice This is true for smallish inputs. But the difference should become larger for bigger inputs. Hell, sometimes ag just refuses to search inputs that are too big. e.g., For a ~9.5GB file: $ time rg '\w+\s+Sherlock Holmes' OpenSubtitles2016.raw.en -c 3003 real 1.608 user 1.105 sys 0.496 maxmem 9473 MB faults 0 $ time ag '\w+\s+Sherlock Holmes' OpenSubtitles2016.raw.en -c ERR: Skipping OpenSubtitles2016.raw.en: pcre_exec() can't handle files larger than 2147483647 bytes. real 0.016 user 0.004 sys 0.011 maxmem 6 MB faults 0
chmln 7y ago
Shameless plug - I also wrote https://github.com/chmln/sd https://github.com/chmln/sd to replace my use of sed.
- saagarjha 7y ago
  > While sed does a whole lot more, sd focuses on doing just one thing and doing it well. I'm sure you already know this, but sed is meant to provide the features that ed does, so sd is quite a bit more limited. Still, I can see how this can be useful, as most invocations of sed end up only really using a handful of its features.
  - chmln 7y ago
    Yeah, there's no hiding that, the fact that it's a find & replace CLI is declared upfront. Although personally, I've only really used sed for find & replace so sd solved my gripes with sed perfectly.
- Ultimatt 7y ago
  alias sd="perl -pe"
JoshuaRLi 7y ago
fd is excellent for casual interactive use, i've had a great UX with it and performance feels on par with GNU find.
- Pawamoy 7y ago
  I don't know if it's because I'm so used to find, but I had a bad UX with fd. This is my thought process each time I use it: "Why separating the extension from the filename? Is this a default? Can we change it? What is the option, -e? Or -e is the option to 'exec'? What's the flag to include hidden files? Or are they already included? Does the pattern comes before the directory? Does it need a directory or does it search it the current one? man fd, man fd, man fd." I guess my brain just refuses to remember these for some reason.
  - JoshuaRLi 7y ago
    Right, there's always going to be some additional cognitive overhead with every new tool you adopt. The question is how much you value its benefits for your use case, and is it worth those costs. If you're so used to find, and it works great for you, then keep using it! It's indeed more powerful and standard than fd, which I think is well-suited for vast majority of simple use cases (casual use). However, here's my reasoning for the first of your questions, as a happy fd user who switched from GNU find. Maybe it can give you insight into why the UX is designed as it is. The extension is distinguished from the filename because it's a common use case (-e jpg less keystrokes than -iname '*.jpg'), it's semantically separate from the filename (IMO) and therefore should not be treated as part of it. And unlike filenames, extensions most often do not need to be pattern matched. If you want to match multiple extensions, just repeat the -e flag e.g. -e jpg -e png.
  - sharkdp 7y ago
    Author of fd here. Thank you for your feedback. If you feel that there is anything we could to to improve fd's UX, it would be great if you could share it on GitHub: https://github.com/sharkdp/fd https://github.com/sharkdp/fd > Why separating the extension from the filename? Is this a default It does not need to be! You can just also just use "fd README.md". Admittedly, the "." will actually search for any character (regex), so if you want to be precise, you need to escape it.

crowbahr 7y ago

Thank you. Find is so complex and looking at fd is a revelation here. Now I feel like all my hard earned cli-fu is a lie.

michaelcampbell 7y ago
Care to share a link? Using fd as a utility name for an os that already uses the word fd as file descriptor is maddeningly hard to find
- thunderbong 7y ago
  I'm assuming it's this - https://github.com/sharkdp/fd https://github.com/sharkdp/fd
- deleted 7y ago
  [deleted]
- h1d 7y ago
  It's the first result for a maddeningly simple search of "cli fd".
hermitdev 7y ago
I remember posting a bug to WSL about supposedly incorrect behavior with find, only to realize that I had incorrect syntax. I forgot to include the escape on the terminating semicolon (also, conveniently never shown the man pages), or maybe it was the enclosing parens around an or for name pattern matching. Anyways, Id been away from *nix for a few years at the time, so I was a bit rusty and soon felt like a moron and closed the bug once I realized my error.
enriquto 7y ago
> Find is so complex and looking at fd is a revelation here. > Now I feel like all my hard earned cli-fu is a lie. fd is also a lie. If you want a decent interface to find just use "find | grep ..."

GolDDranks 7y ago

Have you tried RipGrep (rg)? I think it's the fastest one these days.

rlue 7y ago

Try rg (ripgrep) over ag: https://github.com/BurntSushi/ripgrep https://github.com/BurntSushi/ripgrep

jdc0589 7y ago
ripgrep is incredible
krick 7y ago
Never managed to switch to ripgrep over ag. Performance difference is not that much of a dealbreaker in practice, and rg is not totally backwards-compatible to ag. I don't exactly remember, what was the problem. I guess it has this annoying practice to ignore everything that's in .gitignore, while for ag I could set up an additional .agignore per-project.
- OJFord 7y ago
  Rg similarly supports it's own ignore file, and optionally disabling the default of respecting .gitignore.
- burntsushi 7y ago
  For ripgrep, if you want to use PCRE2 regexes (assuming that's what you meant by backwards compatible), then the -P flag will do that. Otherwise, ripgrep's support for .gitignore should be substantially better than what's in ag. You can use .rgignore just like .agignore. Both ripgrep and ag also support .ignore. These can override whatever is in your .gitignore. See the guide for more details: https://github.com/BurntSushi/ripgrep/blob/master/GUIDE.md#automatic-filtering https://github.com/BurntSushi/ripgrep/blob/master/GUIDE.md#a... > Performance difference is not that much of a dealbreaker in practice This is true for smallish inputs. But the difference should become larger for bigger inputs. Hell, sometimes ag just refuses to search inputs that are too big. e.g., For a ~9.5GB file: $ time rg '\w+\s+Sherlock Holmes' OpenSubtitles2016.raw.en -c 3003 real 1.608 user 1.105 sys 0.496 maxmem 9473 MB faults 0 $ time ag '\w+\s+Sherlock Holmes' OpenSubtitles2016.raw.en -c ERR: Skipping OpenSubtitles2016.raw.en: pcre_exec() can't handle files larger than 2147483647 bytes. real 0.016 user 0.004 sys 0.011 maxmem 6 MB faults 0

chmln 7y ago

Shameless plug - I also wrote https://github.com/chmln/sd https://github.com/chmln/sd to replace my use of sed.

saagarjha 7y ago
> While sed does a whole lot more, sd focuses on doing just one thing and doing it well. I'm sure you already know this, but sed is meant to provide the features that ed does, so sd is quite a bit more limited. Still, I can see how this can be useful, as most invocations of sed end up only really using a handful of its features.
- chmln 7y ago
  Yeah, there's no hiding that, the fact that it's a find & replace CLI is declared upfront. Although personally, I've only really used sed for find & replace so sd solved my gripes with sed perfectly.
Ultimatt 7y ago
alias sd="perl -pe"

JoshuaRLi 7y ago

fd is excellent for casual interactive use, i've had a great UX with it and performance feels on par with GNU find.

Pawamoy 7y ago
I don't know if it's because I'm so used to find, but I had a bad UX with fd. This is my thought process each time I use it: "Why separating the extension from the filename? Is this a default? Can we change it? What is the option, -e? Or -e is the option to 'exec'? What's the flag to include hidden files? Or are they already included? Does the pattern comes before the directory? Does it need a directory or does it search it the current one? man fd, man fd, man fd." I guess my brain just refuses to remember these for some reason.
- JoshuaRLi 7y ago
  Right, there's always going to be some additional cognitive overhead with every new tool you adopt. The question is how much you value its benefits for your use case, and is it worth those costs. If you're so used to find, and it works great for you, then keep using it! It's indeed more powerful and standard than fd, which I think is well-suited for vast majority of simple use cases (casual use). However, here's my reasoning for the first of your questions, as a happy fd user who switched from GNU find. Maybe it can give you insight into why the UX is designed as it is. The extension is distinguished from the filename because it's a common use case (-e jpg less keystrokes than -iname '*.jpg'), it's semantically separate from the filename (IMO) and therefore should not be treated as part of it. And unlike filenames, extensions most often do not need to be pattern matched. If you want to match multiple extensions, just repeat the -e flag e.g. -e jpg -e png.
- sharkdp 7y ago
  Author of fd here. Thank you for your feedback. If you feel that there is anything we could to to improve fd's UX, it would be great if you could share it on GitHub: https://github.com/sharkdp/fd https://github.com/sharkdp/fd > Why separating the extension from the filename? Is this a default It does not need to be! You can just also just use "fd README.md". Admittedly, the "." will actually search for any character (regex), so if you want to be precise, you need to escape it.