Initial motivation: https://github.com/fish-shell/fish-shell/pull/9512#issuecomm...

I switched to the beta on the day it was released and haven't had one single issue with it. That was the smoothest rewrite I've ever seen.

The latest standards for POSIX.2 utilities are here:

https://pubs.opengroup.org/onlinepubs/9799919799/utilities/

I do agree with you that UNIX userland would be miles ahead of where we are now if the POSIX.2 standard could be cajoled out of the '80s.

My preference is PowerShell. It's now open source [1], it has a wide install base, and is cross-platform. It is a bit heavy and slower to start (actually takes seconds), but the cleaness of it's record-based nature versus just string parsing is infinitely refreshing.

[1] https://github.com/PowerShell/PowerShell

1. You can do a superset of POSIX, like BASH and I think Zsh. This gives you a graceful upgrade path while maintaining backward compatibility, at the expense of being somewhat "stuck" in places. Oil is another attempt at exploring how best to use this path.

2. You can throw out POSIX totally, like fish and PowerShell. This lets you really improve things, at the expense of breaking backwards compatibility. IMHO, breaking compatibility is painful enough that it's really really hard to justify.

It's also worth pointing out that you can separate the roles of "interactive shell" and "shell for scripts". It is, for example, perfectly reasonable to use fish for interactive sessions while keeping /bin/sh around and perhaps even preferring dash as its implementation, which gives you compatibility with software while making things friendlier to users. I mean, I say this as someone who writes a lot of sh scripts and between that and years of practice my fingers expect something roughly sh-like, but I hear a lot of good things from folks who just switched their interactive shell to ex. fish.

They also agreed with you in the early 1990's. There are some quotes from Richard Stallman, David Korn (author of AT&T ksh), and Tom Duff (author of rc shell) here lamenting Bourne shell:

https://www.oilshell.org/blog/2019/01/18.html#slogans-to-exp...

A problem with using a Bourne shell compatible language is that field splitting and file name generation are done on every command word

nobody really knows what the Bourne shell’s grammar is

---

But there is a "collective action" problem. Shell was the 6th FASTEST growing language on Github in 2022: https://octoverse.github.com/2022/top-programming-languages

I imagine that, in 2025, there are MORE new people learning POSIX shell/bash, than say any other shell here: https://github.com/oils-for-unix/oils/wiki/Alternative-Shell...

Because they want to get work done for the cloud, or embedded systems, or whatever

Also, LLMs are pretty good at writing shell/bash!

---

Oils is designed to solve the legacy problem. OSH is the most bash-compatible shell in the world [1]:

https://oils.pub/osh.html

and then you also have an upgrade to YSH, a legacy-free shell, with real data structures: https://oils.pub/ysh.html

YSH solves many legacy problems, including the exact problems from the 1990's pointed out above :-)

So to the extent that you care about moving off of bash for scripting, you should probably prefer OSH and YSH to Brush

It looks like Brush aims for the OSH part (compatible), but there is no YSH part (dropping legacy)

(I may run Brush through our spec tests to see how compatible it is, but looking at number of tests / lines of code, I think it has quite some distance to go.)

[1] e.g. early this year, Koichi Murase rewrote bash arrays in OSH to use a new sparse data structure, which I mentioned in the latest blog post. Koichi is the author of the biggest shell program in the world (ble.sh), and also a bash contributor.

https://github.com/oils-for-unix/oils/wiki/The-Biggest-Shell...

I strongly disagree with the notion of only learning one shell language "because what if I telnet into an ancient Sun box and Fish isn't available?" In exactly the same way, I don't exclusively write my programs in C in case some remote host might not have Python or Rust or Fish some day. I'll cross that bridge when I come to it, but in the mean time I want to use something that makes me happy and productive.

But please don't ruin the one great thing about shell scripting, which is that it's still possible to write one shell script that runs everywhere. Yes it's old, antiquated and quirky. It's also very convenient not to have to 1) install new tools on every system, 2) adapt a billion old scripts for a new tool, and 3) learn yet-another-new-paradigm.

Nushell on the other hand takes the (IMO more pragmatic) stance that the underlying app will most likely be writing strings to stdout and it's the shell's job to make it easy to discern the structure in those strings.

Perhaps a powershell wizard can show me that I'm wrong about this, but my feeling is that the powershell equivalent to this nushell is going to either call some external program (in addition to docker) or be quite messy:

    $ docker ps | detect columns | where NAME == "foo"

But a lot of the structured data transformation use cases I encounter, I find myself tackling in DuckDB. It's a little harder for the simplest things, but it pulls ahead quickly. Or at least it does if you need to remember SQL anyway...

That was completed in 2023: Pictures of a Working Garbage Collector

https://www.oilshell.org/blog/2023/01/garbage-collector.html

https://news.ycombinator.com/item?id=34350260

There are two reasons to have a GC:

(1) The AST (aka "lossless syntax tree") is actually GRAPH - it is useful to share nodes.

I think graphs are fairly common for ASTs. Once a node can have multiple parents, then ownership becomes less clear, and errors using arenas can easily cause memory safety bugs.

For example, in Rust, I think you start using Rc<T> and so forth, which is automatic memory management at runtime.

(2) YSH is part of Oils, and it has nested dicts and lists like Python and JavaScript.

Once you have nested dicts and lists, you need GC. We actually have the GC at the "meta-level", and that (somewhat surprisingly) saves a ton of code and bugs.

It's like writing a Python/Ruby interpreter in Java or Go, and re-using the platform GC, rather than writing one specific to your language.

In particular, we don't have GC rooting, ownership, or anything like Py_INCREF/DECREF littered all over the codebase. This makes our implementation like an executable spec!

And that makes it very easy to contribute -- you write typed Python, and it's as fast as shells written in C. I think it's the best of both worlds

---

Something I've pointed out over the years, and which many people find illuminating, is

- bash doesn't have nested maps and arrays -- it only has flat ones. Therefore it doesn't need GC

- awk too - it doesn't need GC, because its data structures are limited - https://news.ycombinator.com/item?id=28785732

- make and cmake too.

I put all these "weak glue" languages in the "string-ish" category. In contrast, YSH gains A LOT of power from having real data structures, and that requires GC.

(Writing a GC was the hardest part of the project -- I think sh/awk/make/cmake left it out for a reason! Even nushell has no GC I believe. fish lacks a GC too.)

YSH has more of the power of Python/JS/Ruby, which if you look at it historically, did "replace" shell and awk for a huge set of problems. (Guido van Rossum specifically mentioned the "hole" between shell and C as a motivation for Python.)

Garbage Collection Makes YSH Different - https://www.oilshell.org/blog/2024/09/gc.html

---

On a different note, if anyone really wants a shell buildable with the Rust toolchain, it would be worthwhile to TRANSLATE Oils to Rust. This will definitely work, because Oils is translated to C++ (completed in early 2024).

You would have to write the runtime, which is around 4K lines for the garbage collector, and 4K lines for the OS bindings. That's a lot easier than writing a bash-compatible shell.

That is, Oils has about 8K lines of hand-written C++ code. Compare with bash which is 162K+ lines of C written from scratch -- it's 20x less.

I think 8K lines of unsafe code is also comparable to Rust binaries. e.g. prior to ~2018, Rust binaries used dlmalloc by default, which is 20-30K lines of C code.

(What's important is that almost all PRs modify safe code only -- it is very easy to review typed Python)

This would be a fun exercise for anybody interested in writing a GC in Rust (which is a hard challenge, with many nontrivial choices). You can write a GC, and get a shell for free, etc.

---

Also, Brush and nushell are different projects ... Oils has both things -- OSH and YSH -- compatible and new

So you actually get 2 shells for free by doing that :-P The "executable spec" strategy took a long time, but it actually worked!