5 ms·

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. Like

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
        burntsushi 2y ago
        It's not strange because ripgrep doesn't understand non-UTF-8 data (unless there's a UTF-16 BOM, in which case, ripgrep will automatically understand it). But you can tell it to: $ echo $'O\xF0uz' | rg -E iso-8859-1 '^.{4}$' Oðuz The person you're responding to has been trolling in this thread (and others) by twisting words and claiming multiple false things. When I've fixed their errors, they don't acknowledge them as mistakes and just keep on twisting words.
        2y ago
BoingBoomTschak 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. Obviously. The topic was Rust CLI tools, that's why my post focused on them. Indeed, my criticism is broader. > 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. This isn't about POSIX or not POSIX, this is about introducing yet another pure convenience feature for something that can easily be achieved with other accompanying (guaranteed to be on the concerned platform) tools. POSIX doesn't create features anyway, it's about describing things that have already become standard; the Austin Group bug tracker is quite explicit about this. > No... it doesn't? ripgrep being compatible with the Unix philosophy is not the same as it being POSIX compatible. Well, just a question of interpretation of "Unix-like goodness". UNIX is both a philosophy and a portability standard (since POSIX == SUSv4). And as I said, doing one thing and doing it well is another facet of that philosophy; finding files != searching in them. > 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? Compatibility != strict rejection of anything else, quite obviously. > 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. Which is why I said vim instead of neovim (even if neovim is clearly better). ------ I think you misunderstand my position because I like a bit of snark: compromising on the "do one thing" part of the UNIX philosophy isn't necessarily something horrible, but it's not an imaginary issue either. I could give other examples (like how the pretty clean xsv became https://github.com/dathere/qsv https://github.com/dathere/qsv) but it really doesn't matter because I think it's more of a popular CLI "apps" thing than Rust alone, even if there's community overlap.
- burntsushi 2y ago
  I can no longer see any coherent point you're trying to make. My point is that you are treating an ideal ("do one thing and doing it well") as an end instead of a means. Moreover, you are treating it as if there is any actual choice in the matter. In reality, the tooling most of us use on the command line violates the Unix philosophy in some way or another. So the question is not "should I adhere to the Unix philosophy?" but "what makes a good user experience?"

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
        burntsushi 2y ago
        It's not strange because ripgrep doesn't understand non-UTF-8 data (unless there's a UTF-16 BOM, in which case, ripgrep will automatically understand it). But you can tell it to: $ echo $'O\xF0uz' | rg -E iso-8859-1 '^.{4}$' Oðuz The person you're responding to has been trolling in this thread (and others) by twisting words and claiming multiple false things. When I've fixed their errors, they don't acknowledge them as mistakes and just keep on twisting words.
      - 2y ago

BoingBoomTschak 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. Obviously. The topic was Rust CLI tools, that's why my post focused on them. Indeed, my criticism is broader. > 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. This isn't about POSIX or not POSIX, this is about introducing yet another pure convenience feature for something that can easily be achieved with other accompanying (guaranteed to be on the concerned platform) tools. POSIX doesn't create features anyway, it's about describing things that have already become standard; the Austin Group bug tracker is quite explicit about this. > No... it doesn't? ripgrep being compatible with the Unix philosophy is not the same as it being POSIX compatible. Well, just a question of interpretation of "Unix-like goodness". UNIX is both a philosophy and a portability standard (since POSIX == SUSv4). And as I said, doing one thing and doing it well is another facet of that philosophy; finding files != searching in them. > 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? Compatibility != strict rejection of anything else, quite obviously. > 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. Which is why I said vim instead of neovim (even if neovim is clearly better). ------ I think you misunderstand my position because I like a bit of snark: compromising on the "do one thing" part of the UNIX philosophy isn't necessarily something horrible, but it's not an imaginary issue either. I could give other examples (like how the pretty clean xsv became https://github.com/dathere/qsv https://github.com/dathere/qsv) but it really doesn't matter because I think it's more of a popular CLI "apps" thing than Rust alone, even if there's community overlap.

burntsushi 2y ago
I can no longer see any coherent point you're trying to make. My point is that you are treating an ideal ("do one thing and doing it well") as an end instead of a means. Moreover, you are treating it as if there is any actual choice in the matter. In reality, the tooling most of us use on the command line violates the Unix philosophy in some way or another. So the question is not "should I adhere to the Unix philosophy?" but "what makes a good user experience?"