Why Sponsor Oils? | blog | oilshell.org
This is the latest version of OSH, a bash-compatible shell:
Please try it on your shell scripts and report bugs! To build and run it, follow the instructions in INSTALL.txt. Please report bugs on Github.
If you're new to the project, see Why Create a New Shell? and the recent FAQ.
This section continues where I left off in What's Happened Since February?, published last month. That post summarized versions 0.6.pre16 through 0.6.pre22.
This section summarizes the last 3 releases, including 0.6.0.
I didn't write an announcement for the 0.6.0 release because the AMA on /r/linux last month generated a lot of feedback. Thanks for the support!
Contributors: let me know if I missed something notable.
test -oto check if an option is set.
-b -c -p -Sflags to
$IFSis empty and when it's unset.
echoare no longer split.
I also triaged spec test failures. See the metrics at the end of this post.
OSH now has a manual, and a list of known differences with other shells. From now on, it will be published with every release.
Changes related to strict options:
shopt, rather than
shopt -s strict-arrayturns an option on, and
-uturns it off.
shopt -s all:strictto turn on all strict options at once.
printf: Implement hex and octal formatting.
&>>no longer take a file descriptor on the left.
hashbuiltin, along with
$PATHcaching. (I didn't see any notable speedups as a result.)
sourceto look up entries in
~, which improves error messages.
configurescript, and in our
$PROMPT_COMMAND, which many bash users use to customize their interactive experience.
xargs. This isn't released yet, but I expect it to play an important role in the Oil language, which will subsume the functionality of these two tools. Why?
findis a recursive expression language, like many other shell sublanguages.
xargsstarts processes and splits strings, just like a shell.
exitbehavior across sourced modules.
There's still plenty more to do. Here are some highlights of major project areas:
(1) OSH language. After recent changes and enhancements to
printf, and brace expansion, it feels like it's "converging". I
expect the upcoming overhaul of assignment builtins to be one of the last
(2) Oil language. I have a concrete design for the
language, but I only recently started implementing it. I also started a
design-docs directory. It will be a lot of work, but we're finally getting
to the main point of the project!
(3) Performance. Still needs a lot of work. Python lets us work quickly and safely, but the code needs to be much faster. I have an idea for a blog post: How to Rewrite Oil in C++, Rust, or D. If you're interested in that, leave a comment.
(4) Documentation. We now have a short manual, but the quick
help builtin need a
lot of work.
(5) The Interactive Shell. I want to make the shell more immediately appealing. People use shell interactively more than they write programs with it.
It's good that Oil is getting more contributions, because I can't do this all by myself. I can use more help!
Please ask questions on oilshell.zulipchat.com.
I'm making more fine-grained announcements there as well. For example, I just wrote a wiki page documenting internal data structures and algorithms:
The metrics below show that everything is pointing in the right direction.
Oil is making solid progress, but there's still a lot more to do!
The last time I reviewed metrics was in the February release of OSH 0.6.pre15. Let's compare it with version 0.6.0 rather than 0.7.pre1, since I like round numbers.
New features and bug fixes made more than 114 new spec test cases pass. I also marked failures as known differences, which led to the failure count dropping:
We have ~1400 new significant lines of code:
And ~2800 new lines of physical code:
The amount of native code was reduced:
This is largely due to forking and modifying
posixmodule.c. I did this to
backport PEP 475 to Python 2,
which fixed our
The binary size stayed almost the same:
The bytecode size increased significantly, out of proportion to the increase in lines of code:
It appears this is partly due to bloat in the code generated by our ASDL implementation. I'll keep an eye on this.
I hope the MyPy / C++ translation will make these metrics obsolete, but I'll continue to keep track of them until that's done.