Why Was Oils Created and What Problems Does It Solve?

Oils was created to give shell users an upgrade path from bash to a better language and runtime — one that keeps your existing shell scripts working while offering a stricter, more modern alternative. It solves two distinct problems at once: the fragility of traditional shell scripting (like silent failures on undefined variables), and the awkwardness shell poses for people coming from Python or JavaScript. The project's own framing is explicit: OSH runs your existing shell scripts, while YSH is "for Python and JavaScript users who avoid shell."

The two problems Oils targets

1. Shell scripts fail in ways that are hard to catch

Traditional shells are permissive by default. A typo in a variable name often expands to an empty string instead of raising an error, so bugs surface far from their cause. Oils' homepage illustrates this directly with a fatal error on an undefined variable:

echo "hello $oops"
^~~~~ fatal: Undefined variable 'oops'

That behavior is the point. Instead of silently substituting nothing, the runtime stops and points at the problem. This is the "better runtime" half of the project's stated goal — catching mistakes at the moment they happen rather than downstream.

2. Shell is unfriendly to programmers from other languages

The second problem is audience fit. YSH is positioned for people who know Python or JavaScript but avoid shell because of its quoting rules, string handling, and data structures. The homepage example shows structured data flowing through the shell:

ysh$ json read < x.json
ysh$ = _reply
(Dict)  {shell: "ysh", fun: true}

Here JSON is parsed into a typed Dict rather than being handled as unstructured text — a capability that maps onto how Python and JavaScript users already expect to work with data.

How the two halves fit together

Both live inside the same oils-for-unix binary, so adopting one doesn't lock you out of the other. The upgrade path framing matters: you can start by running current scripts under OSH, then move individual scripts to YSH as you rewrite them.

Why a new shell instead of just using bash

The project maintains a FAQ and a dedicated post, "Why Create a New Unix Shell?", along with a "Simplest Explanation" and a "Tour of YSH." These exist because the design decisions — strictness, structured data, a Python-like syntax — are deliberate departures from shell tradition, and the authors expect the "why not just fix bash" question. The blog archive spans 2016–2024, so the rationale has been documented over a long development period rather than asserted once.

What this means if you're deciding whether to try it

• If you have a pile of working bash scripts and want fewer silent bugs, OSH is the relevant entry point — it runs existing scripts, and the strictness features address the undefined-variable class of failure.
• If you write Python or JavaScript and have been avoiding shell, YSH is the relevant entry point, particularly if you need to move JSON or other structured data through pipelines.
• If you want to evaluate the reasoning before installing, the FAQ, the "Why Create a New Unix Shell?" post, and the YSH tour are the primary sources.

The project is developed in the oils-for-unix/oils repository on GitHub, with editor support via oils.vim. Build results are published across ci.oilshell.org, mb.oilshell.org, and op.oilshell.org, and user questions are directed to the #oil-help channel on Zulip.