Working Toward an OSH Release

2017-06-19

At the end of the last post, I said I would provide a roadmap for an OSH release. My goal is to release something useful by the end of the summer.

But after drafting the roadmap a few weeks ago, I wasn't sure I could finish everything I wanted to. This post takes stock of the situation.

Areas for Work

The roadmap had four high-level goals:

Finish the build system. OSH can now be built on Linux, but the ./configure and install steps aren't done, and I'd like to build it on at least one other POSIX operating system.
- Background: Rewriting Python's Build System From Scratch.
Polish error handling. Better parse time and runtime error messages will be the main "carrot" for the initial OSH release. But even though we have a good architecture for errors in the Lossless Syntax Tree, there are many individual cases to be polished (hence "the long slog").
- Background: I wrote about parse errors at the beginning of the blog, in this post and others linked from the first blog retrospective.
Run a program found in the wild. I've been testing OSH on my own shell scripts, but I want it to run at least one program written by others. For example, it would be nice to run debootstrap or the toybox build system.
Improve spec test metrics. The number of spec tests that pass and fail roughly capture how complete the shell is. I'd like to have more green and less red upon release.
- Background: Measuring Progress With Tests, Project Metrics

In short, OSH should be easily buildable, run real programs, and give better error messages than bash.

I believe that this will make the OSH 0.1 release interesting and useful. A better bash isn't the entirety of the Oil project, but it's a big milestone.

How Close Are We?

I had done enough work on the build system to be confident about area #1. Forgoing autotools makes this a bigger task than usual, but it didn't seem risky.

And I knew that the parser and ASDL representation of shell were in good shape, having been well tested. I mentioned that on Hacker News that I think parsing is 60% of the work of a shell.

But the error handling was still inconsistent, and I didn't have a good sense of how much work was left on the shell executor and runtime. Basic things worked, but OSH would also fail to run simple scripts.

So, in the last few weeks, I've done extensive work on the runtime, addressing areas #2, #3 and #4. What did I accomplish?

First, I'm happy with the rapid progress on spec tests:

As of June 2: 624 total, 433 passing under OSH, and 141 failing. (mentioned in the last post)
As of June 13: 692 total tests, 534 passing under OSH, and 109 failing. (full results)

So there are over 100 more tests passing in less than 2 weeks.

Secondly, I can run many of my own shell programs, particularly the thousands of lines of build and test automation in the oil repo itself. Running other people's programs still needs work, but I'm hitting expected errors, not big surprises.

After this "sprint", I feel more optimistic about a useful OSH release by the end of summer.

I wrote a lot about the parser last year, but I haven't written much about the shell runtime (*). So even though I said I would concentrate on coding over blogging until the OSH release, I don't want to be completely silent about the runtime.

So the next few posts will be a log of what I did. The idea is to give you a flavor for the long slog of implementing shell features.

For example, I implemented many shell builtins. And I overhauled the abstractions for processes and redirects, which made pipelines and background jobs simpler and more correct.

It's a long list, but I'll call out the interesting parts. Leave a comment if there's a particular part of the runtime you'd like to see covered.

(*) I gave another overview of the parser in this recent Hacker News comment.