6 ms·

> Conform to tools that share a similar niche. If you’re using Rust to make a fast alternative to popular coreutils: model its behavior, help-text, and man page

by hvdijk 4y ago

> Conform to tools that share a similar niche. If you’re using Rust to make a fast alternative to popular coreutils: model its behavior, help-text, and man pages after `ripgrep` and `fd`. I'm surprised by this. Why wouldn't you model the behaviour after grep and find? The fact that ripgrep uses a different regular expression syntax than grep is my main problem with it; if there were a utility with the functionality of ripgrep, but the RE syntax of grep, I would switch over in a heartbeat.

burntsushi 4y ago
What syntax is in grep that you miss from ripgrep? Anyway, there are a lot of different ways to interpret the OP here. Honing in on "use the same regex syntax as grep" seems strange. Maybe they just mean: if you want to see how man pages are produced in Rust programs, then take a look at how these programs do it. Rather than something about the specific content that should go in it. Notice also that the OP started this thought with "alternative to coreutils" program. Rather than a "clone of a coreutils program."
- hvdijk 4y ago
  It's nothing missing, it's just different for no clear reason, and that means remembering different syntaxes depending on which tool I am using at the moment. The one I use most: GNU grep and git grep use `\<` and `\>` for word boundaries, with ripgrep that produces "error: unrecognized escape sequence" and I have to use `\b` instead. (Note: GNU grep and git grep do support `\b` too.) > Maybe they just mean: if you want to see how man pages are produced in Rust programs, then take a look at how these programs do it. I do not think that is what they mean. A man page looks the same to the end user no matter what tools are used to produce it. > Notice also that the OP started this thought with "alternative to coreutils" program. The start of the thought was "Conform to tools that share a similar niche." ripgrep and fd being implemented in Rust are details that are not relevant to an end user. For ripgrep, the "tools that share a similar niche" would not be "tools that are implemented in Rust", it would be "tools that search in files using regular expressions", and I would be happier with a tool that matches the other tools that I use. So actually I completely agree with the author's principle, I just think it was a bad example.
  - burntsushi 4y ago
    > I do not think that is what they mean. A man page looks the same to the end user no matter what tools are used to produce it. And you can look to ripgrep to learn how to produce one! And in particular, how to do it without duplicating docs. In any case, my point is that maybe there is a more expansive viewpoint here that makes sense instead of honing down on to something hyper specific. > It's nothing missing, it's just different for no clear reason, and that means remembering different syntaxes depending on which tool I am using at the moment. Right, so you want a POSIX compatible tool because POSIX is what you're used to and you don't want to use any other interface. Which is fine. Keep using the old stuff. I don't see any good reason to exactly imitate POSIX when I can go build something that I think is better without being constrained by POSIX. For example, I think just having \b is better than having both \< and \>. > I just think it was a bad example. I don't. There's a lot that tools like ripgrep and fd do that the old tools don't do that turn it into its own niche. Like enabling "smart" filtering by default and other things that many consider to be quality of life improvements. So if you're in that niche, then looking to those tools for what they do is a good idea.
    - hvdijk 4y ago
      > Right, so you want a POSIX compatiblr tool because POSIX is what you're used to and you don't want to use any other interface. Well, I would want to use a single RE syntax if possible. It does not have to be POSIX BRE with GNU extensions but that's what is used by the other tools I use. Looking closer, GNU grep, git grep, ripgrep all support PCRE. That might be an okay alternative. It would take some time and effort to switch over. I do not know yet whether it would be worth the effort, but getting used to a different syntax that's used by a wide number of tools seems more useful than getting used to a different syntax that's used by a single tool, no matter how useful the tool. > Which is fine. Keep using the old stuff. I don't see any good reason to exactly imitate POSIX when I can go build something that I think is better without being constrained by POSIX. For example, I think just having \b is better than having both \< and \>. To be clear, \< and \> are GNU extensions, not part of POSIX. I can't really see how making \< and \> errors is better for users than supporting it in addition to \b. I can see an argument that it's not worth the cost to implement the feature, and that's of course one you're entirely within your rights to make, but not that the feature has a negative overall value. For the rest, it seems like you and I have different ideas about what the author meant that are going to be impossible to clear up without input from the author, so I will suggest that we drop that unless and until we do get such input.
ZeroGravitas 4y ago
This is a bit of a misreading. They're not saying base your new version of grep on ripgrep, they're saying if you reimplement a core util then follow the standards of other tools in a similar spirit in that ecosystem. Ripgrep and fd have re-implemented old, well established tools. If they've chosen to diverge from them in a common way then there's probably a very good reason for it, which is worth at least knowing about before doing something different.

by hvdijk 4y ago

burntsushi 4y ago

What syntax is in grep that you miss from ripgrep? Anyway, there are a lot of different ways to interpret the OP here. Honing in on "use the same regex syntax as grep" seems strange. Maybe they just mean: if you want to see how man pages are produced in Rust programs, then take a look at how these programs do it. Rather than something about the specific content that should go in it. Notice also that the OP started this thought with "alternative to coreutils" program. Rather than a "clone of a coreutils program."

hvdijk 4y ago
It's nothing missing, it's just different for no clear reason, and that means remembering different syntaxes depending on which tool I am using at the moment. The one I use most: GNU grep and git grep use `\<` and `\>` for word boundaries, with ripgrep that produces "error: unrecognized escape sequence" and I have to use `\b` instead. (Note: GNU grep and git grep do support `\b` too.) > Maybe they just mean: if you want to see how man pages are produced in Rust programs, then take a look at how these programs do it. I do not think that is what they mean. A man page looks the same to the end user no matter what tools are used to produce it. > Notice also that the OP started this thought with "alternative to coreutils" program. The start of the thought was "Conform to tools that share a similar niche." ripgrep and fd being implemented in Rust are details that are not relevant to an end user. For ripgrep, the "tools that share a similar niche" would not be "tools that are implemented in Rust", it would be "tools that search in files using regular expressions", and I would be happier with a tool that matches the other tools that I use. So actually I completely agree with the author's principle, I just think it was a bad example.
- burntsushi 4y ago
  > I do not think that is what they mean. A man page looks the same to the end user no matter what tools are used to produce it. And you can look to ripgrep to learn how to produce one! And in particular, how to do it without duplicating docs. In any case, my point is that maybe there is a more expansive viewpoint here that makes sense instead of honing down on to something hyper specific. > It's nothing missing, it's just different for no clear reason, and that means remembering different syntaxes depending on which tool I am using at the moment. Right, so you want a POSIX compatible tool because POSIX is what you're used to and you don't want to use any other interface. Which is fine. Keep using the old stuff. I don't see any good reason to exactly imitate POSIX when I can go build something that I think is better without being constrained by POSIX. For example, I think just having \b is better than having both \< and \>. > I just think it was a bad example. I don't. There's a lot that tools like ripgrep and fd do that the old tools don't do that turn it into its own niche. Like enabling "smart" filtering by default and other things that many consider to be quality of life improvements. So if you're in that niche, then looking to those tools for what they do is a good idea.
  - hvdijk 4y ago
    > Right, so you want a POSIX compatiblr tool because POSIX is what you're used to and you don't want to use any other interface. Well, I would want to use a single RE syntax if possible. It does not have to be POSIX BRE with GNU extensions but that's what is used by the other tools I use. Looking closer, GNU grep, git grep, ripgrep all support PCRE. That might be an okay alternative. It would take some time and effort to switch over. I do not know yet whether it would be worth the effort, but getting used to a different syntax that's used by a wide number of tools seems more useful than getting used to a different syntax that's used by a single tool, no matter how useful the tool. > Which is fine. Keep using the old stuff. I don't see any good reason to exactly imitate POSIX when I can go build something that I think is better without being constrained by POSIX. For example, I think just having \b is better than having both \< and \>. To be clear, \< and \> are GNU extensions, not part of POSIX. I can't really see how making \< and \> errors is better for users than supporting it in addition to \b. I can see an argument that it's not worth the cost to implement the feature, and that's of course one you're entirely within your rights to make, but not that the feature has a negative overall value. For the rest, it seems like you and I have different ideas about what the author meant that are going to be impossible to clear up without input from the author, so I will suggest that we drop that unless and until we do get such input.

ZeroGravitas 4y ago

This is a bit of a misreading. They're not saying base your new version of grep on ripgrep, they're saying if you reimplement a core util then follow the standards of other tools in a similar spirit in that ecosystem. Ripgrep and fd have re-implemented old, well established tools. If they've chosen to diverge from them in a common way then there's probably a very good reason for it, which is worth at least knowing about before doing something different.