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!

Explore on GitHub Read 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

jgoerzen/hsh · linked in 2 of the same discussions
mbrubeck/compleat · linked in 2 of the same discussions
ngs-lang/ngs · linked in 2 of the same discussions

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

This week on Hacker News

Nov 8–Nov 15 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/15/2026, 8:03:49 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.

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.
Period	Start (UTC)	End (exclusive, UTC)	Mentions	Submissions	Comments
2016	2016-01-01 00:00:00 UTC	2017-01-01 00:00:00 UTC	3	0	3
2017	2017-01-01 00:00:00 UTC	2018-01-01 00:00:00 UTC	13	0	13
2018	2018-01-01 00:00:00 UTC	2019-01-01 00:00:00 UTC	9	0	9
2019	2019-01-01 00:00:00 UTC	2020-01-01 00:00:00 UTC	27	2	25
2020	2020-01-01 00:00:00 UTC	2021-01-01 00:00:00 UTC	52	3	49
2021	2021-01-01 00:00:00 UTC	2022-01-01 00:00:00 UTC	41	2	39
2022	2022-01-01 00:00:00 UTC	2023-01-01 00:00:00 UTC	27	3	24
2023	2023-01-01 00:00:00 UTC	2024-01-01 00:00:00 UTC	16	1	15
2024	2024-01-01 00:00:00 UTC	2025-01-01 00:00:00 UTC	17	2	15
2025	2025-01-01 00:00:00 UTC	2026-01-01 00:00:00 UTC	20	2	18

What Hacker News says

9 sources

chubot·Dec 29, 2018

I agree that not just bash, but POSIX shell is beyond salvaging, at least for many use cases where it should be applied. The way I think of it is that I can't tell my (former) coworkers or my sister to learn to program shell in 2018 "with a straight face". More than 50% of them had Ph.D.'s in some other field like statistics, math, biology, or physics -- i.e. the kind of person who has no problem with Python. But they would struggle with shell or make. They're the kind of people Mike Bostock (author of d3) wrote this post about Make for [1]. He's absolutely right that they should use Make, because like shell it's a great tool to combine different programs that weren't designed to be combined. But I feel like this is basically a losing battle -- I don't see that shell or make is an exciting thing for most people to learn, even though it

Read the rest

would make them more productive and increase the quality of their work. I think that a language free of legacy would go a long way. I guess I can see POSIX sh being used when confined to the lower level of an OS, by specialists. But I think it has a lot more potential than that. I'd say it's more important now than 10 years ago, because there's so much more software out there and systems are increasingly built of large heterogeneous parts. ---- FWIW I mentioned Morbig here [2], along with several other shell parsers, like ShellCheck in Haskell and shfmt in Go. [1] https://bost.ocks.org/mike/make/ [2] https://github.com/oilshell/oil/wiki/ExternalResources

In Anatomy of a shell

chubot·Dec 28, 2018

FWIW yash is an impressive and mature project that seems to overlap with the goals of mrsh: https://yash.osdn.jp/index.html.en Yash, yet another shell, is a POSIX-compliant command line shell written in C99 (ISO/IEC 9899:1999). Yash is intended to be the most POSIX-compliant shell in the world while supporting features for daily interactive and scripting use. I've installed the Ubuntu package and poked around at it a bit. Its source code seems well-written, and it even contains its own line editing library (i.e. the functionality of GNU readline). It looks like it's still being developed, and magicant is the original author: https://github.com/magicant/yash I mentioned it here (and just added a proper link): https://github.com/oilshell/oil/wiki/ExternalResources I wrote some notes about POSIX here: http://www.oilshell.org/blog/2018/01/2

Read the rest

8.html#limit-to-posix

In Anatomy of a shell

chubot·Nov 7, 2018

What kind of language was it, and what was ambiguous about it? Do you control the language or is it an existing language? FWIW here is a small, self-contained recursive-descent parser I recently wrote in Python (that recognizes certain C data definitions). https://github.com/oilshell/oil/blob/master/build/cpython_de... I think your structure is bit odd because Nodes are "smart". That is, the style is more object oriented than functional. If you clearly separate out the input data (lexer), code for the parser, and the resulting data it will be better. Pretty much all compilers and interpreters follow this structure, even ones in Java (e.g. in Terrence Parr's books). AST nodes should be dumb (no methods related except trivial ones for pretty printing). I think you might be getting confused between clauses of the grammar and nodes in an

Read the rest

AST. They are similar but they don't have a one-to-one correspondence. (Generating a heterogeneous AST is generally more useful than generating a homogeneous parse tree.) In my case I return tuples; in bigger projects I use Zephyr ASDL. (https://news.ycombinator.com/item?id=17852049) Parser() is a class because it holds the state of the current token. That is necessary for LL(1) parser. It feels a bit redundant sometimes, but it is a straightforward and useful structure once you get used to it. Writing an LL(1) recursive descent parser by hand is a good exercise even if you plan to use a parser generator eventually. IME it helps to write out the grammar in comments next to the code. On the other hand, I have found that what parsing technique works best is very closely related to the actual language. It could be that something like Owl works for you language, but it's not obvious and would require some justification IMO.

In Owl: Parser generator for visibly pushdown languages

chubot·Sep 24, 2018

I'm working in this area right now if you want to help :) http://www.oilshell.org/ I took a survey of what people use here: https://lobste.rs/s/z96uyr/survey_what_shell_completion_scri... That produced a link to this old project which tried to do something like what you want: a completion system that works for multiple shells (in this case, by code generation from a DSL) https://github.com/mbrubeck/compleat It's easy for you to say "completion should be specified in the binary" without actually specifying HOW. That's not straightforward, although I agree it's a good goal. ----- Right now I'm implementing a bash-compatible completion API, and I'm actually getting pretty far without too much code. git-completion.bash is 3000 lines of code, so it's actually easier to emulate bash (with all its warts) than to write an entirely new completio

Read the rest

n system AND THEN write 3000+ lines of git completion in that hypothetical system. https://github.com/oilshell/oil/issues/175 FWIW git is also the biggest completion script in the zsh source tree by a factor of 2 -- ~7000 lines IIRC with the next largest being around ~3000 lines. Eventually Oil should have something better than bash completion, but the first step is taking advantage of ~40K lines of existing code in the bash-completion [1] project. I also looked at emulating zsh but that would be a lot more work than emulating bash. [1] https://github.com/scop/bash-completion

In Creating a bash completion script

no_wizard·May 15, 2018

Sure, I agree, for specific tasks. Just like a hammer is a better tool than a screw driver for putting nails in a block of wood. Thats my point. They're tools not lifestyle choices. Learn your tools, know your tools, don't be afraid of other people's tools. They all, usually, have some sort of value. I might as well note this too: I am speaking in broad strokes, you're going to be able to pinhole this as much as you want because of that. I'm simply suggesting that if your immediate reaction to how another organization uses these tools to replace A with B at a certain level is "this is clearly inferior" instead of "well, what can I learn from this" well, there's the problem. I used to think programmers/computer scientists where open minded people. Then I realized as a whole it tends to be we're only open minded if its within the domain we

Read the rest

chose to be most active in Still far and away better than any other folks I've met, of course, but this is really a community culture problem, which is why I find it so counter productive. Alternatives to bash? Many do exist. zsh is bash compatible but does implement its own tools and subsets. If you're looking for something that removes the bash syntax there is powershell, which does run on Linux/macOS now as well: https://github.com/PowerShell/PowerShell Then of course, there is oil shell: https://github.com/oilshell/oil which is more like a subset of bash (and somewhat close to the idea of stripping away all the legacy stuff) Then there is xonsh: lets you use python as a basis for most everything http://xon.sh/ The stalwart fish: https://fishshell.com/ fish shell has alot of niceties and a more object oriented syntax (kind of) and for the daring there is ergonomica: https://ergonomica.readthedocs.io/en/latest/ which has a lisp like syntax as does https://github.com/dundalek/closh which uses clojure and its syntax and i'm sure there are more.

In Shell Style Guide

chubot·Mar 6, 2018

Yes absolutely! I've long been interested in multi-stage programming for this reason. Oil is filled with this pattern: do a bunch of metaprogramming at startup to make some data. Then use that immutable data for the rest of the program. There are very much two stages. I think Lua-Terra might be closest to the thing I want, although I haven't had a chance to play with it: http://terralang.org/ I mention Bob Nystrom's language Magpie, which has an interesting model. Do the type checking at main(), not after parsing! But everything that happens before main(), at import time, is metaprogramming! A Problem with Type Checking http://www.oilshell.org/blog/2016/11/30.html I think I want to do compilation/optimization right before main(), not just type checking. It's all a bit vague right now, but I think OPy can go in this direction. Havin

Read the rest

g the compiler written in its own language facilitates this. You can run code first, and then compile. This post is also related: Type Checking vs. Metaprogramming; ML vs. Lisp http://www.oilshell.org/blog/2016/12/05.html Also note that C++ is a two-stage language too. In fact Herb Sutter just proposed that they unify the two languages. Like you can use STL with constexpr at compile time. Link on this page: https://github.com/oilshell/oil/wiki/Metaprogramming I think your suggestion is exactly what I've been thinking, so if you want to talk more about it / work on it, feel free to mail me :) The code needs a bit of work but I think it's a promising direction.

In Building Oil with the OPy Bytecode Compiler

chubot·Feb 1, 2018

Absolutely. In fact, the bash manual explicitly refers to GNU parallel for this use case! I use xargs -P all over the Oil codebase, which does what you want. The trick is to end the file with "$@", and then invoke xargs -P 4 -- $0 my-func. That way xargs can run arbitrary shell functions, not just something like sh -c "..." ! I'm going to write a blog post about this. I also do this with find -exec $0 myfunc ';' https://github.com/oilshell/oil/blob/master/test/spec-runner... However I think Oil will have something built-in to make this parallel process more friendly. I will probably implement xargs so it can run my own shell scripts without GNU xargs, but then add a nicer syntax. (Probably "each", since that's what xargs really does.) This gets into your other question about standard utils, which I'll answer now. Short answer: yes

Read the rest

I would like something like that, it's just a matter of development time and priorities. I agree with the problem you point out.

In Why Create a New Unix Shell?

chubot·Feb 1, 2018

FWIW I have your project on my wiki page :) https://github.com/oilshell/oil/wiki/ExternalResources I guess what you mean by embedded is that it should be an embedded DSL in a full-fledged programming language? I don't quite agree, since there are at least 20 projects like that on the wiki page, none of which is popular. Probably the most popular one is eshell, in Emacs Lisp? But if there's something I don't know about I'd be interested in hearing it. This idea goes back at least 20 years, e.g. to scsh. And it hasn't taken off. But certainly I don't begrudge anyone if their favorite environment is Racket and they want to stay in Racket. That's a perfectly reasonable thing. It's just not what I would expect anyone besides racket users to use. One reason I'm interested in shell because it's the lowest common denominator between differen

Read the rest

t groups of programmers. C/C++ programmers, use it heavily, Python, Ruby, JS programmers, Go, etc. Everybody uses it.

In Why Create a New Unix Shell?

chubot·Jan 31, 2018

I agree, but the first step is to make a shell. I imagine it will be like Vi or Emacs -- it can write to a terminal, or have its own UI. I have been keeping a wiki page: https://github.com/oilshell/oil/wiki/Interactive-Shell Although honestly I won't get to any of this in the near future.

In Why Create a New Unix Shell?