This is not a rousing endorsement of the Unix shell environment. Maybe that should be rewritten in something else too (probably not Rust, Rust is probably not a good choice for this - but something that is designed in such a way that it is easy to test would be nice!).
There's nothing about rust that makes things hard to test. Actually the embedded test framework makes it easier than C. But what really matters is the public interface of those tools and that's got an extensive test suite available. It doesn't matter which language is used internal for those tests to run.
I meant that Rust is probably not a good choice for a new shell scripting environment, not that Rust is hard to test. I was responding to the claim "Unix shell environments have always been ad hoc and poorly tested", which is a bad thing and is worth fixing in and of itself.
> This is not a rousing endorsement of the Unix shell environment.
It's surely not. The question wasn't how to rewrite the shell environment to be more "endorseable", though.
The point is that we have a half century (!) long history of writing code to this admittedly fragile environment, with no way to audit usage or even find all the existing code (literally many of the authors are retired or dead).
So... it's just not a good place to play games with "Look Ma, I rewrote /usr/bin/date and it's safe now!" Mess with your own new environments, not the ones that run the rest of the world please.
Maybe it's more important to rewrite half a century of poorly documented and specified shell scripts that are so embedded that their existence gets in way of rewriting fundamental Unix command line utilities, than it is to rewrite those utilities themselves. Any time someone makes the claim "we shouldn't touch this code, it's fragile" that state of affairs is itself bad. Our free software source code shouldn't be some poorly understood black box that we're afraid to touch for fear of breaking something, and if it is that is something we should fix.
