5 ms·

> GNU grep discards the Unix philosophy in all sorts of places too. Who ever claimed that GNU was a proponent of the UNIX philosophy? Certainly not me. > What

> GNU grep discards the Unix philosophy in all sorts of places too. Who ever claimed that GNU was a proponent of the UNIX philosophy? Certainly not me. > What's actually happening here is that what matters is the user experience, and the Unix philosophy is a means, not an end, to improve the user experience Yes and no. The expression "user experience" implies that all users are the same and benefit from the same philosophy of software interface design. > Besides, you can drop ripgrep into a shell pipeline just like you would grep. All that Unix-y goodness is still there. The "Unix-y goodness" isn't only defined by what it can do, but also what it can't do. I don't want to turn this into a suckless rant, so I won't. Also, not having a mode giving it POSIX grep compatibility really flies in the face of that claim: I want my scripts to work on BSD, MacOS and even Solaris/AIX without having to install stuff. ------ I know I may sound very smug but believe me when I say that I really like some of these utils and the care put into them (and I know you're the author of ripgrep) and that I'm no UNIX OpenBSD user (Plan 9 exists for a reason, and I favor CL over C/Go any time of the day). But I really see them as optimizing for/targeting the VSCode/Zed crowd, instead of the vim/emacs one, if you know what I mean.

burntsushi 2y ago
OK, so you phrased your criticism very narrowly toward "lots of these Rust CLI tools," but in actuality, your criticism applies way more broadly than that. Likely to just about all of GNU's tooling, for example. And probably BSD's and busybox's tooling too. Even busybox isn't above implementing POSIX+some, and AFAIK none of them provide a strict "POSIX only" mode. Which is fine, but now your position is more "old man yelling at clouds" than it is something specific about the Rust tools. (And to be clear, I'm not above yelling at clouds now and then.) > Also, not having a mode giving it POSIX grep compatibility really flies in the face of that claim No... it doesn't? ripgrep being compatible with the Unix philosophy is not the same as it being POSIX compatible. I didn't say you could use ripgrep in any place you could use grep in a drop-in compatible way. I said you could use it in shell pipelines. As in, it inter-operates with other tooling in a Unix-y way. And besides, I don't know of any grep that has such a mode. How do you know you aren't using a grep flag that isn't available in other grep implementations? > But I really see them as optimizing for/targeting the VSCode/Zed crowd, instead of the vim/emacs one, if you know what I mean. Nope, I don't. I've been a vim (now neovim) user for decades. And neovim even uses ripgrep by default over grep if it's installed.
- oguz-ismail 2y ago
  [flagged]
  - burntsushi 2y ago
    A tool doesn't need to support locales to be used in a shell pipeline. The Unix philosophy and shell pipelines were born long before POSIX locales. I even specifically contrasted this with POSIX compatibility. So it seems to me like you're disingenuously interpreting my words at this point. @dang more trolling
    - oguz-ismail 2y ago
      [flagged]
      - burntsushi 2y ago
        That isn't true. ripgrep will happily pass through data it gets as-is. It just itself doesn't support locales. Commands do not need to have locale support to be used in shell pipelines. `rg foo | rg -v bar` is an example that has nothing to do with locales but demonstrates that ripgrep can be used in shell pipelines.
        oguz-ismail 2y ago
        It is. Consider foo | grep -E '^.{4}$' | bar If foo prints $'O\u011Fuz' and LC_ALL is set to a valid UTF-8 locale, bar will receive what foo printed. If foo prints $'O\xF0uz' and LC_ALL is assigned a valid ISO-8859 locale, again, bar will receive what foo printed; because foo, bar, and grep are compatible. You can't have that with ripgrep; you'll have to modify the shell script in between or worse, manually parse LC_ALL and hope ripgrep supports the encoding
        whytevuhuni 2y ago
        I found this interesting, so I tried to test it: On LC_ALL=en_US.UTF-8: $ echo $'O\u011Fuz' | grep -E '^.{4}$' Oğuz $ echo $'O\u011Fuz' | rg '^.{4}$' Oğuz On LC_ALL=en_US.ISO-8859-1: $ echo $'O\xF0uz' | grep -E '^.{4}$' O�uz $ echo $'O\xF0uz' | rg '^.{4}$' It strangely doesn't find anything at all: $ echo $'O\xF0uz' | rg '^.*$' | wc -c 0 It only does once the $ anchor is removed: $ echo $'O\xF0uz' | rg '^.*' | wc -c 5
stouset 2y ago
> Who ever claimed that GNU was a proponent of the UNIX philosophy? Certainly not me. Nothing was specific to GNU in that comment. `-r` is available in BSD grep too. You are being needlessly pedantic and avoiding the actual points being made while doing so. > Yes and no. The expression "user experience" implies that all users are the same and benefit from the same philosophy of software interface design. No, it doesn’t. You have literally made that up out of whole cloth, but it isn’t how anyone else I’m aware of defines “user experience”. As BurntSushi pointed out, ripgrep is even designed to adapt to different means of use: as a standalone command, as a utility in a pipe, and others. Improving the usability for one use-case isn’t necessarily at the cost of others. > I want my scripts to work on BSD, MacOS and even Solaris/AIX without having to install stuff. So your very reasonable desire to stick with POSIX for shell scripts… means we shouldn’t ever make new tools? I’m genuinely failing to understand your point here. In fact, having a “grep compatibility flag” would very literally be the opposite of the UNIX philosophy you’re holding up elsewhere. ripgrep isn’t grep. It isn’t trying to be grep. It’s something new and different and (in some use-cases) better. The old thing still exists and if you want to use it for whatever reason… just do that?
- BoingBoomTschak 2y ago
  > Nothing was specific to GNU in that comment. `-r` is available in BSD grep too. You are being needlessly pedantic and avoiding the actual points being made while doing so. Where's the actual point in "others do it too"? > No, it doesn’t. You have literally made that up out of whole cloth, but it isn’t how anyone else I’m aware of defines “user experience”. That's not a question of definition, but of use in an English sentence. If you say "this is good for user experience", you implicitly group all users together. I say some users prefer tools that do only one thing. ripgrep itself acknowledges that "despite initially not wanting to add every feature under the sun to ripgrep, over time, ripgrep has grown support for most features found in other file searching tools". And that's fine! But not for everybody. > As BurntSushi pointed out, ripgrep is even designed to adapt to different means of use: as a standalone command, as a utility in a pipe, and others. Improving the usability for one use-case isn’t necessarily at the cost of others. If I like the "finding files with auto filtering" part of ripgrep, how can I use it to feed another grep or even another tool? If it had been designed with the aforementioned philosophy, it would have been "ripfind" + "ripgrep" and maybe a "ripfg" pretty interface on top. > So your very reasonable desire to stick with POSIX for shell scripts… means we shouldn’t ever make new tools? I’m genuinely failing to understand your point here. > In fact, having a “grep compatibility flag” would very literally be the opposite of the UNIX philosophy you’re holding up See my other reply: I love new tools, but "UNIX-like goodness" is also about portability (as in SUS), not just the philosophy. More of a misunderstanding than anything else, really. A flag would be impossible, but introspection based on argv[0] (like Busybox) wouldn't be that far-fetched. But yeah, clearly ripgrep isn't trying to replace only grep, that was a mistake on my part. As an addendum, the "UNIX philosophy" had a lot of crap parts (e.g. bytes as universal interchange format) and UNIX itself is a very poor implementation of said philosophy (after all, g/re/p itself is pointless porcelain over (s)ed, heh), I'm not sure discussing it seriously without specifying which part (like "do one thing") is very productive.
School-Cotton 2y ago
> But I really see them as optimizing for/targeting the VSCode/Zed crowd, instead of the vim/emacs one, if you know what I mean. At this point it sounds like you're making a purely aesthetic/cultural judgment, rather than a technical one. ripgrep works just fine with emacs; I have "C-c p s r" bound to "run ripgrep in current project" and use it almost every day.

burntsushi 2y ago

OK, so you phrased your criticism very narrowly toward "lots of these Rust CLI tools," but in actuality, your criticism applies way more broadly than that. Likely to just about all of GNU's tooling, for example. And probably BSD's and busybox's tooling too. Even busybox isn't above implementing POSIX+some, and AFAIK none of them provide a strict "POSIX only" mode. Which is fine, but now your position is more "old man yelling at clouds" than it is something specific about the Rust tools. (And to be clear, I'm not above yelling at clouds now and then.) > Also, not having a mode giving it POSIX grep compatibility really flies in the face of that claim No... it doesn't? ripgrep being compatible with the Unix philosophy is not the same as it being POSIX compatible. I didn't say you could use ripgrep in any place you could use grep in a drop-in compatible way. I said you could use it in shell pipelines. As in, it inter-operates with other tooling in a Unix-y way. And besides, I don't know of any grep that has such a mode. How do you know you aren't using a grep flag that isn't available in other grep implementations? > But I really see them as optimizing for/targeting the VSCode/Zed crowd, instead of the vim/emacs one, if you know what I mean. Nope, I don't. I've been a vim (now neovim) user for decades. And neovim even uses ripgrep by default over grep if it's installed.

oguz-ismail 2y ago
[flagged]
- burntsushi 2y ago
  A tool doesn't need to support locales to be used in a shell pipeline. The Unix philosophy and shell pipelines were born long before POSIX locales. I even specifically contrasted this with POSIX compatibility. So it seems to me like you're disingenuously interpreting my words at this point. @dang more trolling
  - oguz-ismail 2y ago
    [flagged]
    - burntsushi 2y ago
      That isn't true. ripgrep will happily pass through data it gets as-is. It just itself doesn't support locales. Commands do not need to have locale support to be used in shell pipelines. `rg foo | rg -v bar` is an example that has nothing to do with locales but demonstrates that ripgrep can be used in shell pipelines.
      - oguz-ismail 2y ago
        It is. Consider foo | grep -E '^.{4}$' | bar If foo prints $'O\u011Fuz' and LC_ALL is set to a valid UTF-8 locale, bar will receive what foo printed. If foo prints $'O\xF0uz' and LC_ALL is assigned a valid ISO-8859 locale, again, bar will receive what foo printed; because foo, bar, and grep are compatible. You can't have that with ripgrep; you'll have to modify the shell script in between or worse, manually parse LC_ALL and hope ripgrep supports the encoding
        whytevuhuni 2y ago
        I found this interesting, so I tried to test it: On LC_ALL=en_US.UTF-8: $ echo $'O\u011Fuz' | grep -E '^.{4}$' Oğuz $ echo $'O\u011Fuz' | rg '^.{4}$' Oğuz On LC_ALL=en_US.ISO-8859-1: $ echo $'O\xF0uz' | grep -E '^.{4}$' O�uz $ echo $'O\xF0uz' | rg '^.{4}$' It strangely doesn't find anything at all: $ echo $'O\xF0uz' | rg '^.*$' | wc -c 0 It only does once the $ anchor is removed: $ echo $'O\xF0uz' | rg '^.*' | wc -c 5

stouset 2y ago

> Who ever claimed that GNU was a proponent of the UNIX philosophy? Certainly not me. Nothing was specific to GNU in that comment. `-r` is available in BSD grep too. You are being needlessly pedantic and avoiding the actual points being made while doing so. > Yes and no. The expression "user experience" implies that all users are the same and benefit from the same philosophy of software interface design. No, it doesn’t. You have literally made that up out of whole cloth, but it isn’t how anyone else I’m aware of defines “user experience”. As BurntSushi pointed out, ripgrep is even designed to adapt to different means of use: as a standalone command, as a utility in a pipe, and others. Improving the usability for one use-case isn’t necessarily at the cost of others. > I want my scripts to work on BSD, MacOS and even Solaris/AIX without having to install stuff. So your very reasonable desire to stick with POSIX for shell scripts… means we shouldn’t ever make new tools? I’m genuinely failing to understand your point here. In fact, having a “grep compatibility flag” would very literally be the opposite of the UNIX philosophy you’re holding up elsewhere. ripgrep isn’t grep. It isn’t trying to be grep. It’s something new and different and (in some use-cases) better. The old thing still exists and if you want to use it for whatever reason… just do that?

BoingBoomTschak 2y ago
> Nothing was specific to GNU in that comment. `-r` is available in BSD grep too. You are being needlessly pedantic and avoiding the actual points being made while doing so. Where's the actual point in "others do it too"? > No, it doesn’t. You have literally made that up out of whole cloth, but it isn’t how anyone else I’m aware of defines “user experience”. That's not a question of definition, but of use in an English sentence. If you say "this is good for user experience", you implicitly group all users together. I say some users prefer tools that do only one thing. ripgrep itself acknowledges that "despite initially not wanting to add every feature under the sun to ripgrep, over time, ripgrep has grown support for most features found in other file searching tools". And that's fine! But not for everybody. > As BurntSushi pointed out, ripgrep is even designed to adapt to different means of use: as a standalone command, as a utility in a pipe, and others. Improving the usability for one use-case isn’t necessarily at the cost of others. If I like the "finding files with auto filtering" part of ripgrep, how can I use it to feed another grep or even another tool? If it had been designed with the aforementioned philosophy, it would have been "ripfind" + "ripgrep" and maybe a "ripfg" pretty interface on top. > So your very reasonable desire to stick with POSIX for shell scripts… means we shouldn’t ever make new tools? I’m genuinely failing to understand your point here. > In fact, having a “grep compatibility flag” would very literally be the opposite of the UNIX philosophy you’re holding up See my other reply: I love new tools, but "UNIX-like goodness" is also about portability (as in SUS), not just the philosophy. More of a misunderstanding than anything else, really. A flag would be impossible, but introspection based on argv[0] (like Busybox) wouldn't be that far-fetched. But yeah, clearly ripgrep isn't trying to replace only grep, that was a mistake on my part. As an addendum, the "UNIX philosophy" had a lot of crap parts (e.g. bytes as universal interchange format) and UNIX itself is a very poor implementation of said philosophy (after all, g/re/p itself is pointless porcelain over (s)ed, heh), I'm not sure discussing it seriously without specifying which part (like "do one thing") is very productive.

School-Cotton 2y ago

> But I really see them as optimizing for/targeting the VSCode/Zed crowd, instead of the vim/emacs one, if you know what I mean. At this point it sounds like you're making a purely aesthetic/cultural judgment, rather than a technical one. ripgrep works just fine with emacs; I have "C-c p s r" bound to "run ripgrep in current project" and use it almost every day.