[Toybox] Shell Compatibility Reports from Oils - ~800 tests passing

[Andy Chu]

Hi Rob,

The author of brush was also interested in running our spec tests, so
I went ahead and created the "Bashix" repo with discussions and wiki
pages:

https://github.com/bashix-spec/bashix/discussions

- How to Run Oils spec tests
- Idea for a common test format
  - a simple way to get started, by pooling some effort

https://github.com/bashix-spec/bashix/wiki/List-of-Shell-Test-Suites

> I'm usually interested in more tests. And I never claimed 100% bash
> conformance: even BASH doesn't have 100% bash conformance. (Half my
> arguments with Chet _cause_ version skew, which I see as a bug and he
> sees as a feature. I ask him to explain a corner case and he FIXES it,
> but then what do I put in the test suite if I want to pass TEST_HOST on

I agree with this problem -- I've hit it many times.  I added this
quote to the Bashix README.

I notice that if you ask a question on the bash mailing list about
bash behavior, sometimes they will just read you the source code.

Meaning they didn't think about that case before you asked.

> > But then I learned there are TWO shells in Rust aiming at bash
> > compatibility, both started in 2022 - in this thread
> > https://news.ycombinator.com/item?id=43908368
>
> Yup, there you go. Two of them.

At first I thought these projects overlapped a lot with OSH, but when
I look at the home page

https://brush.sh/

https://github.com/shellgei/rusty_bash/

they are focused on the INTERACTIVE use case.  OSH is both an
interactive shell and a language, like toysh.

But I discovered many years ago that interactive scripts can almost be
considered a different dialect of bash.  And there are many features
that are interactive only -- e.g. the completion and history APIs,
bind -x, etc. which are tightly coupled to GNU readline.

So I think it may help to view these projects as slightly different,
as complementary.  There is a lot of work to go around.

I would certainly understand if the authors didn't think say toysh
could be finished, and are trying their own approach.  That is valid


> > So I thought you may be interested in this.
>
> Not really. I've never met a rust developer who had any argument for
> rust other than "I hate C" and "writing more C is a SIN you HEATHEN".

Although memory safety isn't the #1 problem with shells (e.g.
ShellShock was not a memory safety bug), I think it's a good reason.

(And btw I don't use Rust myself.  I don't like long compile times.)

FWIW I contributed some memory safety fixes to toybox over 9 years ago:

http://lists.landley.net/pipermail/toybox-landley.net/2016-March/016106.html

http://lists.landley.net/pipermail/toybox-landley.net/2016-March/016178.html

http://lists.landley.net/pipermail/toybox-landley.net/2016-March/016179.html

I felt then that shell requires a ton of parsing, and parsing in C
inevitably leads to memory safety bugs.  In the last 9 years, the
world has moved in the direction that this isn't acceptable, so I'm
glad I didn't write Oils in C or C++.

(It actually started as 3000 lines of C++ in March 2016, but I
abandoned that approach.)

> Which doesn't explain why to use _that_ language for kernels instead of
> instead of go, swift, zig... And that's kernels, why not do userspace in
> any of the bytecode languages? (I personally like Lua.)

Although Lua is faster than Python, it's not fast enough to implement
a shell in.

Oils is written in Python-based DSLs, with a bunch of metaprogramming.
It uses very fine-grained static types (in the style of algebraic data
types, checked with MyPy).

That is good for concentrating on ALGORITHMS, which I felt was
important for long-term project with a clean codebase.

But it's bad for speed.

So we wrote a Python-to-C++ translator, and a small runtime with
garbage-collected data structures.  This took a LONG time, but is now
done.

And OSH is now FASTER than bash, in both I/O and computation.

e.g. it runs autotools configure scripts in 90-95% the elapsed time of
bash or dash:

https://oils.pub/release/latest/benchmarks.wwz/osh-runtime/

And it runs computations like "Fibonacci" faster than bash.

Actually this was confirmed today by an independent user -
https://news.ycombinator.com/item?id=44407626

> Bash exists. I'm trying to do a self-contained project so I can get a
> minimal system down to 4 packages (compiler, kernel, libc, cmdline) so
> you can build something like tinycc+linux+musl+toybox and then build
> Linux From Scratch under the result.

Yes, I liked your Aboriginal project!  And I think bootstrapping is
important for a shell.

Rust code is not really bootstrappable, and there's only one
implementation of the Rust compiler.

The OSH tarball is small -- you get about ~115K lines of standard C++
11 (with absolutely no dependence on Python)

https://oils.pub/osh.html

So all you need is a C++ compiler, a shell, and ~30 seconds to use it.
And you get a 2 MB executable, which also has YSH.

YSH is more like Python -- it has garbage-collected data structures and JSON.

https://oils.pub/ysh.html

My interest was more in moving PAST bash.  Like you say, "bash exists".

I think there is value in having another bash implementation -- OSH
has precise error messages and so forth.  But really bash is a bad
language that we should move on from -- that is the point of YSH.

Obviously bash will exist for decades to come, but I think it's
important to have a path out of it.

I don't think having 4 different "sorta bash" projects helps anybody,
and that is the idea behind "Bashix" -- to SHARE more of the work.  At
least the tests.

----

I wonder if OSH  does everything you want ?

I think it would be easier to say write a C++ to C translator, or a
Python to C translator, than to finish toysh.

Yes toysh has a very small binary, but it's also the least compatible
shell, and I thought you said you've worked on it since ~2007 or so.

https://pages.oils.pub/spec-compat/2025-06-26/renamed-tmp/binary-sizes.txt

OSH has been funded by https://nlnet.nl since 2022, and for the next
6-12 months, we are going to make a push towards showing you can build
a distro like Alpine Linux with OSH.

We need some more people to participate in that effort, e.g. to reduce
bugs into isolated test cases.

So if anyone is interested, you can be paid for that work!

---

It's fine to work on code "for no reason".  But if you're going to say
the Rust projects have no reason for existing, then what's the reason
for toysh existing?

If you take into account what I just mentioned:

- That OSH is by far the most bash-compatible shell
- It's bootstrappable, requiring only a C++ compiler
- It's faster than bash
- It has less source code than bash (~64K lines vs. 162K lines)
- It's memory safe

Then I think toysh looks less appealing.

If you are not interesting in USING OSH, then I would say it's still
beneficial to just COPY the algorithms into C.  When I look at the
blog, e.g. about alias, there is a lot "language reverse engineering"
that we've ALREADY done, that you are repeating.

As another example, Koichi Murase is a contributor to OSH, and he
wrote the biggest shell program in the world (ble.sh), and overhauled
our array implementation based on his extensive knowledge:

https://oils.pub/blog/2025/05/release-0.27.0.html#complete-overhaul-of-bash-arrays-koichi-murase

At the current rate, it seems like it will be years, if not a DECADE,
before you can even start thinking about that stuff.

---

So I think "Bashix" could be about sharing some more work.  My first
reaction is that "Bashix" should just be OSH, because we wrote it as
an "executable spec".

But there are a few places where that is not true -- the reports show
that sush and brush pass some tests that OSH doesn't:

https://pages.oils.pub/spec-compat/2025-06-26/renamed-tmp/spec/compat/DELTA-osh.html#t:DELTA-osh=9d

So we are going to work on that.

toysh passes 5 tests that OSH doesn't -
https://pages.oils.pub/spec-compat/2025-06-26/renamed-tmp/spec/compat/DELTA-osh.html#t:DELTA-osh=7d

Some of those are "intentional strictness" that is trivial to relax.
e.g. we disallowed 'FOO=bar break' on purpose, but it's easy to allow
it.


> You may have seen the long threads on here with Chet Ramey, the bash
> maintainer. I've also had discussions about standards with Elliott
> Hughes the ANdroid base OS maintainer.
>
> Alas, neither of us wants to maintain a standard because it's a TON of work.

Yeah I think the "default outcome" is that there are going to be 4
"sort of bash" projects, which is not going to do users any favors.

Because there will be a lack of coordination, and sharing of labor.

But at least if you want to run Oils tests, the "Bashix" forum is now
the place to discuss that.

OSH is not running upstream bash tests yet, so I hope to import those.
   And the sush project is running the bash-completion test suite.

So it probably makes sense to at least share the effort of TESTING the
shells, if not the implementation.

And using the same test suite makes it easier to do comparisons.

> I'm usually interested in more tests. And I never claimed 100% bash
> conformance: even BASH doesn't have 100% bash conformance. (Half my

At first, I thought that OSH could be a "subset of bash".

But that is pretty much useless to users like Alpine Linux, the Nix distro, etc.

They're not interested in writing in a subset -- they're interested in
running the big mess that they ALREADY have.

The people maintaining the distros now did NOT write the bash scripts!
 So they don't even have the knowledge to fix the bash scripts, if
they wanted to.

---

Anyway, that's long enough for now.  I hope you'll take some time kick
the tires on OSH, and see if it does what you want toysh to do.

And to participate in the Bashix discussion!  At the very least, you
can get some more tests out of it.

Although honestly there are already more tests than we have time to
fix (the bottleneck is CONTRIBUTORS, not tests), I think the common
tests are useful because they enable comparisons like the one I just
sent.

My hope is that some shell authors will see that they are duplicating
a huge amount of work that OSH has already done.  (And that OSH is
BOTH bootstrappable, and memory safe.)

In the next year, if we show that OSH can be used to build real
distros, without bash, then I think this will be more apparent to
everyone.

Andy