HackerReposA FIELD GUIDE TO OPEN SOURCE
ProSponsor the shelf♧ 0
← Back to top all-time
oils-for-unix
oils
Python2016–2025
oils-for-unix / oils

oils

Oils is our upgrade path from bash to a better language and runtime. It's also for Python and JavaScript users who avoid shell!

Command LineWeb DevelopmentLanguages & CompilersSystems & Infrastructure
Explore on GitHubRead Hacker News discussions
35Distinct people
225Mentions
1Explicit recommenders
3.4KGitHub stars
REPOSITORY AT A GLANCE

What to know before exploring

What it is

Oils is our upgrade path from bash to a better language and runtime. It's also for Python and JavaScript users who avoid shell!

GitHub

Where it is used

No documented product use was verified in the last source check.

What people are saying

There are Usenix papers on bash and ksh -- I archived the ksh one here: http://www.oilshell.org/archive/ksh-usenix.pdf The surprising thing to me is that ksh was Lua-like in…

chubot used a recommendation phrase. 4 indexed comments match. This is a phrase match, not a verdict.

No classified warning is attached to this page. Read the discussions before treating silence as approval.

Also in these discussions

Mentioned in the same Hacker News threads. That is not proof they are substitutes.

This week on Hacker News

Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 5:04:57 PM UTC.

No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.

Mentions over time

HN mentions by year225 dated mentions

Observed mentions: 2016-11-26 10:24:57 UTC to 2025-11-06 22:34:08 UTC.

02040602016-01-01 00:00:00 UTC to 2017-01-01 00:00:00 UTC (exclusive): 3 mentions; 0 submissions, 3 comments20162017-01-01 00:00:00 UTC to 2018-01-01 00:00:00 UTC (exclusive): 13 mentions; 0 submissions, 13 comments2018-01-01 00:00:00 UTC to 2019-01-01 00:00:00 UTC (exclusive): 9 mentions; 0 submissions, 9 comments2019-01-01 00:00:00 UTC to 2020-01-01 00:00:00 UTC (exclusive): 27 mentions; 2 submissions, 25 comments2020-01-01 00:00:00 UTC to 2021-01-01 00:00:00 UTC (exclusive): 52 mentions; 3 submissions, 49 comments20202021-01-01 00:00:00 UTC to 2022-01-01 00:00:00 UTC (exclusive): 41 mentions; 2 submissions, 39 comments2022-01-01 00:00:00 UTC to 2023-01-01 00:00:00 UTC (exclusive): 27 mentions; 3 submissions, 24 comments2023-01-01 00:00:00 UTC to 2024-01-01 00:00:00 UTC (exclusive): 16 mentions; 1 submissions, 15 comments2024-01-01 00:00:00 UTC to 2025-01-01 00:00:00 UTC (exclusive): 17 mentions; 2 submissions, 15 comments2025-01-01 00:00:00 UTC to 2026-01-01 00:00:00 UTC (exclusive): 20 mentions; 2 submissions, 18 comments2025

Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.

View mention counts and date ranges
UTC ranges include their start and exclude their end. Select a period to filter the source evidence.
PeriodStart (UTC)End (exclusive, UTC)MentionsSubmissionsComments
20162016-01-01 00:00:00 UTC2017-01-01 00:00:00 UTC303
20172017-01-01 00:00:00 UTC2018-01-01 00:00:00 UTC13013
20182018-01-01 00:00:00 UTC2019-01-01 00:00:00 UTC909
20192019-01-01 00:00:00 UTC2020-01-01 00:00:00 UTC27225
20202020-01-01 00:00:00 UTC2021-01-01 00:00:00 UTC52349
20212021-01-01 00:00:00 UTC2022-01-01 00:00:00 UTC41239
20222022-01-01 00:00:00 UTC2023-01-01 00:00:00 UTC27324
20232023-01-01 00:00:00 UTC2024-01-01 00:00:00 UTC16115
20242024-01-01 00:00:00 UTC2025-01-01 00:00:00 UTC17215
20252025-01-01 00:00:00 UTC2026-01-01 00:00:00 UTC20218

What Hacker News says

225 sources
chubot·Nov 6, 2025
> language with well-defined semantics That would certainly be nice! That's why we have been overhauling shell with https://oils.pub , because shell can't be described as that right now It's in extremely poor shape e.g. some things found from building several thousand packages with OSH recently (decades of accumulated shell scripts) - bugs caused by the differing behavior of 'echo hi | read x; echo x=$x' in shells, i.e. shopt -s lastpipe in bash. - 'set -' is an archaic shortcut for 'set +v +x' - Almquist shell is technically a separate dialact of shell -- namely it supports 'chdir /tmp' as well as cd /tmp. So bash and other shells can't run any Alpine builds. I used to maintain this page, but there are so many problems with shell that I haven't kept up ... https://github.com/oils-for-unix/oils/wiki/Shell-WTFs OSH is the most bash-compa
Read the rest
tible shell, and it's also now Almquist shell compatible: https://pages.oils.pub/spec-compat/2025-11-02/renamed-tmp/sp... It's more POSIX-compatible than the default /bin/sh on Debian, which is dash The bigger issue is not just bugs, but lack of understanding among people who write foundational shell programs. e.g. the lastpipe issue, using () as grouping instead of {}, etc. --- It is often treated like an "unknowable" language Any reasonable person would use LLMs to write shell/bash, and I think that is a problem. You should be able to know the language, and read shell programs that others have written
In You should write an agent
chubot·Oct 2, 2025
Oils (https://oils.pub/) | Language Engineer / Debugger of Other People’s Cursed Shell Programs / Writer | REMOTE (non-US) | 50 euros/hour Oils is our upgrade path from bash to a better language and runtime. We’ve been awarded a 4th grant from https://nlnet.nl, and our focus is to show that OSH can be the ONLY shell on a Unix system, which is hard It looks like we will reach this goal! Other than me, there are 4 people working PART TIME on this, and we can use more help. If you like hunting down difficult bugs, and are skilled at Unix and Python, this could be a good fit. Most bugs are too hard for 1 person to fix by themselves, so communication is important. And writing good test cases is important. We’re also paying people to do polished writing, since we'd like to spread the word Starting from 131, we’re down to 41 disagreements betw
Read the rest
een OSH and sh/ash/bash, when building ~1600 packages in Alpine Linux https://op.oils.pub/aports-build/published.html Anyone who's not “scared” of these bugs is probably a good fit, and you can do as much or as little as you like. This is also an opportunity to get deeper into the interpreter Communication happens on Zulip, and we also have video meetings approximately every 2 weeks I'll have a blog post explaining this work soon, but feel free to e-mail me if this (unusual) job matches your interests. Any questions are very welcome, and you can dip your toes in to see if it works for you I wrote this page a few years ago to help people assess the fit: https://github.com/oils-for-unix/oils/wiki/Where-Contributor... The job is remote-only, and we slightly prefer non-US contributors due to our funding Tech stack: Python, Shell, perhaps C++ Contact: andychup@gmail.com
In Ask HN: Who is hiring? (October 2025)
chubot·Sep 30, 2025
That's a major reason that https://oils.pub/ started out with the POSIX- and bash-compatible OSH, and then added YSH on top of it (while removing legacy) In YSH, you can do everything that bash does with processes, because OSH is the most bash-compatible shell in the world: https://pages.oils.pub/spec-compat/2025-09-14/renamed-tmp/sp... For example, I think many of the newer shells don't implement process subs, a ksh/bash thing: ysh-0.35$ diff -u <(seq 2 3) <(seq 1 4) ... +1 2 3 +4 YSH also improves on bash by checking the error code from process subs, which bash simply ignores: cat <(seq ) <(seq 1 4); echo hi ^~ [ interactive ]:39: errexit PID 693013: Command failed with status 1 BUT you can also do Python like stuff, pretty much exactly like ABS's example on the home page var obj = {}
Read the rest
for n in (1 ..< 10) { if (n % 2 === 0) { setvar obj[str(n)] = 6 ** 2 # no rand function now } } = obj # pretty print with = # => (Dict) {'2': 36, '4': 36, '6': 36, '8': 36} (hm I wonder if str(n) should be relaxed ...) ABS is listed on this wiki page, along with many Python- and JavaScript- influenced shells: https://github.com/oils-for-unix/oils/wiki/Alternative-Shell... https://koi-lang.dev/ https://github.com/alexst07/shell-plus-plus https://hush-shell.github.io/ But YSH is the only one that has a process runtime that's a SUPERSET of bash --- I also want to add to add xargs-like functionality to the runtime. I mentioned in the latest release that bash/xargs actually has a problem with waiting for processes in parallel, while ALSO checking for errors: Eight Releases of Oils in 6 Months: https://oils.pub/blog/2025/09/releases.html
In The ABS programming language
chubot·Aug 20, 2025
BTW if you follow the philosophy of using bash as your CI so it runs locally (mentioned by several people in this thread), then you can use the same CI logic on sourcehut and Github Actions. Both of them provide VMs where you can run anything, and bash is of course there on every image. We do that for https://oils.pub/ sourcehut yaml: https://github.com/oils-for-unix/oils/tree/master/.builds github yaml: https://github.com/oils-for-unix/oils/tree/master/.github/wo... They both call the same shell. The differences are: * We use Github's API to merge on green; right now we don't have the same for sourcehut (since Github is the primary repo) * Github Actions provides way more resources. They are kind of "locking projects in" by being free. This post on NixOS gives a hint of htat https://blog.erethon.com/blog/2025/07/31/how-nixos-is-built/
Read the rest
The monthly cost for all the actions in July of 2025 came out to a bit over 14500 USD which GitHub covers in its entirety. So I think many projects are gradually sucked in to Github because it is indeed quite generous (including us, which annoys me -- we run more tasks on Github than sourcehut, even though in theory we could run all on sourcehut) --- BUT I think it is a good idea to gradually consolidate your logic into shell, so you can move off Github in the future. Open source projects tend to last longer than cloud services. This already happened to us -- we started using Travis CI in 2018 or so, and by 2021, it was acquired and the free tier was removed
In Modern CI is too complex and misdirected (2021)
pdimitar·Jul 21, 2025
> There is hope that LLMs can be used to convert shell scripts to other languages, because they can make the jump that experienced devs have learned to avoid: rewriting from scratch. What else do you do when refactoring in small steps is not feasible? There were some languages shown in HN that compile to sh/bash (like oilshell[0]). I would think that's also a viable vector of attack but not sure how viable it actually is i.e. maintainers might have moved on for various reasons. [0] https://github.com/oils-for-unix/oils
In Debugging Bash Like a Sire
chubot·Jul 7, 2025
I'll keep an eye out for the blog post! We're still working (intermittently) on a better shell <-> terminal interface. We actually did the first demo back in 2021, before we became aware of Warp. And here is an update from a month ago, which mentions Warp / IntelliJ / VSCode: https://lobste.rs/s/viwe6p/open_source_can_t_coordinate#c_px... That is, we did some demos with a nushell contributor, to see if there is a protocol that Oils and nushell can agree on. The big constraints seems to be bash and zsh. (I still believe in graceful evolution, not building a "inner platform") I think these 2025 demos went pretty well, but it's still in the demo/research phase. After working in this area for many years, I think the bottleneck is coordination, mentioned here - https://lobste.rs/s/ejcoud/dreaming_smel_shell i.e. there are many separate pro
Read the rest
jects doing similar things, and most of them get to 80% or so. I like that you mention a lot of prior art! More links: https://github.com/oils-for-unix/oils/wiki/Headless-Shell-Pr... Feel free to join any of the Zulip discussions ... there are a bunch of prototypes floating around, but nothing set in stone!
In Operators, Not Users and Programmers
chubot·Jun 25, 2025
Wow great bug! > Bash forgot to reset errno before the call. For about 30 years, no one noticed I have to say, this part of the POSIX API is maddening! 99% of the time, you don't need to set errno = 0 before making a call. You check for a non-zero return, and only then look at errno. But SOMETIMES you need to set errno = 0, because in this case readdir() returns NULL on both error and EOF. I actually didn't realize this before working on https://oils.pub/ --- And it should go without saying: Oils simply uses libc - we don't need to support system with a broken getcwd()! Although a funny thing is that I just fixed a bug related to $PWD that AT&T ksh (the original shell, that bash is based on) hasn't fixed for 30+ years too! (and I didn't realize it was still maintained) https://www.illumos.org/issues/17442 https://github.com/oils-for-un
Read the rest
ix/oils/issues/2058 There is a subtle issue with respect to: 1) "trusting" the $PWD value you inherit from another process 2) Respecting symlinks - this is the reason the shell can't just call getcwd() ! if (*p != '/' || stat(p, &st1) || stat(".", &st2) || st1.st_dev != st2.st_dev || st1.st_ino != st2.st_ino) p = 0; Basically, the shell considers BOTH the inherited $PWD and the value of getcwd() to determine its $PWD. It can't just use one or the other!
In Deep Down the Rabbit Hole: Bash, OverlayFS, and a 30-Year-Old Surprise
chubot·Jun 13, 2025
Oh cool, I'd be interested to read about the issues you had expressing Rust syntax in Vim! And yes, there are a whole bunch of limitations: - C function definitions - harder than JavaScript because there's no "function". It's still syntactic, but probably requires parsing, not just lexing. - C variable definitions - I'd call this "coarse semantic analysis", not coarse parsing! Because of the "lexer hack" - Indentation as you mention - there was a thread where someone was complaining that treesitter had 2 composed parsers for Markdown -- block and inline -- although I'm not sure if this causes a problem in practice? (feedback appreciated) --- But I did intend for YSH to be easier to parse than shell, and that actually worked, because it fits quite well in Vim! I noted here that OSH/bash has 10 lexer modes -- I just looked and it's up to
Read the rest
~16 now https://www.oilshell.org/blog/2019/02/07.html#2019-updates Whereas YSH has 3 mutually recursive modes, and maybe 6 modes total. --- On the "coarse semantic analysis", another motivation is that I found Github's semantic source browser a bit underwhelming. Not sure if others had that same experience. I think it can't really be accurate because it doesn't have a lot of build time info. So I think they could have embraced "coarseness" more, to make it faster Although maybe I am confusing the UI speed with the analysis speed. (One reason that this was originally a Codeberg link is that Codeberg/Forejo's UI is faster, without all the nav stuff) There are some related links here, like How To Build Static Analyzers in Orders of Magnitude Less Code: https://github.com/oils-for-unix/oils/wiki/Polyglot-Language...
In Three Algorithms for YSH Syntax Highlighting
chubot·May 7, 2025
I am not sure if this helps or not, but if you want a bash-compatible shell on Windows, translating Oils to Ada, or porting it to Windows could be easier than adding bash arrays https://news.ycombinator.com/item?id=43910883 (similar comment about Rust) Bash arrays are extremely hairy, with many corner cases, and differ from bash version to version. And in particular, the shell code in Nix DOES RELY on these corners (e.g. https://www.oilshell.org/blog/2024/06/release-0.22.0.html) --- I mentioned in another comment that Koichi Murase, who is a bash contributor, and wrote the largest shell program in the world, just overhauled the bash array support in OSH A few relevant test files -- Koichi added a huge number recently: https://oils.pub/release/0.29.0/test/spec.wwz/osh-py/array-s... https://oils.pub/release/0.29.0/test/spec.wwz/osh-py/arra
Read the rest
y-a... https://oils.pub/release/0.29.0/test/spec.wwz/osh-py/ble-idi... Our tests are thorough enough that we ROUTINELY find bugs in bash, like integer overflow bugs. Koichi also knows about the differences between say bash 4.3, 4.4, 5.0, 5.1, etc. Because he wrote a very large program that uses bash arrays all over the place. --- Feel free to use our tests in any case (other shells like the Scheme shell used to bootstrap Guix have) And feel free to post a message to https://github.com/oils-for-unix/oils if you're interested or have questions
In Brush (Bo(u)rn(e) RUsty SHell) a POSIX and Bash-Compatible Shell in Rust
chubot·May 6, 2025
I think everyone agrees with you, and they did back in say 2016 when I started https://oils.pub 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-un
Read the rest
ix/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...
In Brush (Bo(u)rn(e) RUsty SHell) a POSIX and Bash-Compatible Shell in Rust
chubot·May 6, 2025
Hm I wasn't aware of this project, it seems to have started in 2022 Other than OSH, it seems to be the only shell that aims for POSIX/bash compatibility, out of dozens of alternative shells: https://github.com/oils-for-unix/oils/wiki/Alternative-Shell... As far as I know, OSH is the most POSIX- and bash-compatible shell: Nine Reasons to Use OSH - https://oils.pub/osh.html If I have time, I will run this through our spec tests: https://oils.pub/release/0.29.0/test/spec.wwz/osh-py/index.h... --- About this part: There are a number of other POSIX-ish shells implemented in a non-C/C++ implementation language OSH is implemented in an unusual style -- we wrote an "executable spec" in typed Python, and then the spec is translated to C++. That speeds it up anywhere from 2x-50x, so it's faster than bash on many workloads e.g. a "fibonacci" is fast
Read the rest
er than bash, as a test of the interpreter. And it makes 5% fewer syscalls than bash or dash on Python's configure (although somehow this doesn't translate into wall time, which I want to figure out) It's also memory safe, e.g. if there is no free() in your code, then there is no double-free, etc. --- As mentioned on the OSH landing page, YSH is also part of the Oils project, and you can upgrade with shopt --set ysh:upgrade If you want JSON and so forth, e.g. ysh$ json read < x.json ysh$ = _reply (Dict) {shell: "ysh", fun: true} YSH aims to be the "ultimate glue language" - https://oils.pub/ysh.html
In Brush (Bo(u)rn(e) RUsty SHell) a POSIX and Bash-Compatible Shell in Rust

Showing the 15 most recent of 225 sources. Enable JavaScript to search and browse every indexed mention.

MAKE YOURSELF AT HOME

A few shortcuts

/
Search the collection
?
Open this guide
Esc
Close dialogs and navigation

Your saved repositories and interests stay in this browser.