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:
basename
calc
cat
cksum
cp
cur
du
echo
ed
false
free
grep
init
ion
login
ls
lua
mkdir
ps
pwd
realpath
rem
rm
rmdir
seq
sh
shutdown
sleep
tar
touch
true
wc
yes
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
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?
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 env::args()?
No 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, tr.
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?
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.