First of all: congratulations for the new site and forum. I have been following Redox for a while. It is great to see this awesome project growing.
Just as way to learn Rust I have built a few command line tools mimicking existing tools. Redox source was a very nice for inspiration and comparison purpose. I think this is great entry point for people that want to collaborate as they are rather isolated. How about making a list of missing/desired command line tools so people can contribute?
Also related to this, I built a small git clone implementing 4 of the plumbing commands.
clap was very useful to make it work. However, it seems that Redox as well as other established projects are just using vainilla rust for this. Is there any particular reason?
The reason to not use clap originally was because adding dependencies required getting the source as a git submodule and compiling it with rustc. This is very recently no longer the case, so you could use clap for additional tools. We may eventually use it for coreutils as well.
I know we don’t have xargs yet, which would be nice.
A full list of what we have is:
Anything that you regularly use that isn’t there would be nice. You can add it to coreutils if it is a core program for a Unix system, or extrautils if it is not
Thinking about this,
tr would be very nice to have
I think an even better place for people to start than creating new utils is improving the ones we have. They could all be more feature complete, more efficient, more documented, etc.
And what is the guidelines for arguments, defaults, etc. Are you trying to mimic existing tools or you are willing to choose saner (this is subjective) defaults when worth it?
Generally, we prefer a GNU-style interface. The tools should differ minimally from well-etablished tools.
I think by GNU-style, you mean the
I finally had some time to work on this and I have ready the code for
cut. It is just missing the command line argument parsing. Are we ok about using
clap or shall I continue using directly
For consistency, I would prefer using
gzip yet either, as far as I can tell from coreutils and extrautils repos. That would be nice to have.
Gzip header support in rust-compress is incomplete (although there is an alternative gzip header parser in flate2), so this might be not as straightforward a project as, say,
Would you be interested in pull requests to switch the existing tools to clap?
Sure. If you can port it to Redox (shouldn’t be that hard), then yeah, go ahead!
I’m currently working on a pure-Rust
tr utility, with the intention of getting it into Redox.
Additionally, I’ve opted for a fully GNU-compatible program because it looked like an interesting challenge. Turns out I used way less of
tr than it’s actually capable of… I’ve already implemented parsing goddamn octal sequences for specifying ASCII codes (hello 70s!). After I’m done with GNU compatibility I’ll add a -u key or something to specify Unicode codepoints in hexadecimal. (You’re welcome to strip away GNU compatibility and make that the default mode if you think that’s a good idea).
Also, right now the commandline argument parsing is done by hand, and it doesn’t handle abbreviated commandline options clamped together, like
tr -sd (while
tr -s -d works fine). I don’t feel like reimplementing that part by hand, so if you port Clap or some other parser for command-line options to Redox please let me know and I’ll switch my tr to it ASAP.
If the team thinks it would be a good idea, I can contribute an implementation of the GNU Parallel program which I am currently working on. In some ways, it’s already much better than the original GNU implementation.
I’m not on the team, but your Parallel looks very interesting to me due to its low overhead.
However, my use cases involve processing a million entities, which do not fit into an argument list (at least on Linux). Adding stdin or --arg-file support looks like a nice side-project for a weekend, so I might just do that. Are there any serious blockers for implementing that, which I have not noticed by skimming the code?
Support for stdin has existed since the first release. The specific lines of code that enables that support is here.
So you use a rust clone of grep, but have you thought about replacing/complementing it with ripgrep which is an another pure rust search tool that is really fast.
That is something we have discussed here: https://github.com/redox-os/redox/issues/746 , even involving the developer of ripgrep
Oh, oops! Nevermind me then.