nushell VS oil

Compare nushell vs oil and see what are their differences.


A new type of shell (by nushell)


Oil is a new Unix shell. It's our upgrade path from bash to a better language and runtime. It's also for Python and JavaScript users who avoid shell! (by oilshell)
Our great sponsors
  • InfluxDB - Build time-series-based applications quickly and at scale.
  • SonarLint - Clean code begins in your IDE with SonarLint
  • SaaSHub - Software Alternatives and Reviews
nushell oil
159 194
22,639 2,445
1.3% 1.3%
9.9 9.2
6 days ago 4 days ago
Rust Python
MIT License GNU General Public License v3.0 or later
The number of mentions indicates the total number of mentions that we've tracked plus the number of user suggested alternatives.
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.


Posts with mentions or reviews of nushell. We have used some of these posts to build our list of alternatives and similar projects. The last one was on 2023-01-25.
  • Why should I care wether my shell is POSIX compliant?
    6 projects | | 25 Jan 2023
    I've been using nushell as my daily driver shell for a while. It's still very much in development, but it's got some nice features, like Windows cross compatibility, proper data types, and syntax highlighting
  • FUSTA: quickly & easily edit, slice, 'n dice ((very) large) FASTA files
    3 projects | | 17 Jan 2023
    Now, I guess the deeper question is ‶is the text-based, line-delimited, pipe-oriented, interaction model between programs that don't know each other still relevant″; and we have seen new, more structured, approaches being tested, for instance with PowerShell or NuShell.
  • VanadiumOS: Portable, multi-user Unix-like OS
    4 projects | | 9 Jan 2023
    You can install PowerShell on Linux now, if you like - or there's nushell:
  • What’s everyone working on this week (1/2023)?
    15 projects | | 2 Jan 2023
    I'll add the long awaited support for nushell in broot.
  • Telegraph and the Unix Shell
    8 projects | | 31 Dec 2022
    But that and xplr are both programs used within the shell and don't address that the shell is still outputting plain-dumb-dataless-text. promotes right on the homepage Everything is data so it's exciting to see and hope for a better future!
  • Rust-shell: what features you would you like to see in a shell ?
    5 projects | | 28 Dec 2022
    I don't understand what you mean by Graphics integration or graphical frontend. Do you have an example? Instead of du - I recommend dust. The data features - are basically the features of nushell, are you using it? Regarding the variables - excellent idea, I will implement this. What do you mean by menu creation? What syntax would you use for "skip next line"?
  • GNU nano is my editor of choice (2021)
    4 projects | | 28 Dec 2022
    > Different components can integrate and coordinate through standards.

    We've tried that and for the most part, it doesn't actually work in practice. Hell, it doesn't even work between standard Unix programs. They don't "integrate and coordinate" at all. They just push unstructured text around, and in some cases that's sufficient to perform some very basic compound tasks.

    There is an upcoming project though that tries to make Unix pipelines work the way they are supposed to: Nushell[1]. It has real composability with strongly typed data that flows between commands.

    Guess how they're doing it? Yup, that's right: They're building it all as a monolithic system where the entire pipeline is supervised and interpreted by the shell. Unix is too fragmented and standards are too difficult to develop and implement for any other approach to be realistically feasible. "Small programs" are an evolutionary dead end.


  • Like seriously why does not one does it ?
    15 projects | | 17 Dec 2022
    Finally, I really do recommend looking into Nushell. It should give you a much better idea of how a shell could work if it weren't tied to ASCII blobs as its core data type.
    15 projects | | 17 Dec 2022
    If you're discontent with the state of shell scripting, you should give nushell a try:
  • Life is much simpler with bash
    4 projects | | 26 Nov 2022
    If structured data is what excites you about pwsh, you should check out nushell: It is cross-platform like pwsh, and takes a similar approach to structured data, but has a much simpler syntax that I find more readable and much nicer to type than pwsh.


Posts with mentions or reviews of oil. We have used some of these posts to build our list of alternatives and similar projects. The last one was on 2023-01-23.
  • Show HN: Shite: The little hot-reloadin' static site maker from shell
    14 projects | | 23 Jan 2023
    Nice! I also use inotifywait for hot reload when writing

    I never heard of the xdotool method ... although it sounds like it has some drawbacks?

  • We Need to Know LR and Recursive Descent Parsing Techniques
    7 projects | | 17 Jan 2023
    I agree with 90%-95% of the article. I would phrase it more pithily as:

    1. Use recursive descent for recognizing existing languages, where you have a good test corpus. (And very good point about testing INVALID inputs too!)

    2. Use grammars to design new languages

    I follow this with -- the compatible OSH is a huge recursive descent parser, and Oil is designed with a grammar.

    Guy Steele and Russ Cox also mentioned this methodology -- design the language with a grammar, and then implement it a second time by hand. Then you REALLY know it! :)

    It is definitely possible to not know the language you're implementing / creating!


    As an undergrad, I never tried to design a language, or even thought about it honestly. But I agree that undergrads should know of both approaches, without necessarily getting into the details of CFGs.

    It would be a mistake to just teach recursive descent.

  • Pictures of a Working Garbage Collector
    2 projects | | 12 Jan 2023 )

    I would just use shell scripts to saturate 64-128 cores, rather than dealing with slow schedulers and distributed file systems.

    But garbage collectors and memory management are a main reason you can't use all of a machine from one process. There's just so much room for contention. Also the hardware was trending toward NUMA at the time, and probably is even more now, so processes make even more sense.

    All of that is to say that I'm a little scared of multi-threaded GC ... especially when linking in lots of third party libraries.


    But of course there are many domains where you don't have embarrassingly parallel problems, and writing tight single- or multi-threaded code is the best solution!

    Some more color here:

    I wonder if Clasp has any support for multi-process programming? Beyond Unix pipes, you could also use shared memory and maybe some semaphores to synchronize access, and avoid copying. I think of that as sort of "inverting" the problem. Certain kinds of data like pointer-rich data is probably annoying to deal with in shared memory, but there are lots of representations for data and I imagine Lisps could take advantage of some of them, e.g.

  • Why Use Make
    10 projects | | 11 Jan 2023
    Hm yes now I remember that point about how the data is anonymous Python objects that you can pass around to functions.

    Are there any open source examples? I looked around the github account, but I mostly remember this tool

    I'd be interested in seeing the Python config and Ninja output, to see how it works. Right now it looks to me like the dependencies are more implicit than explicit, e.g. with your copen example


    The system I ended up with is more like Bazel, but it's not building containers, so it's a slightly different problem. But I'm interested in building containers incrementally without 'docker build'.

    I like the apt lockfile idea definitely ... However I also have a bunch of other blobs and tarballs, that I might not want to check into git. I guess you just put those in OSTree?

    Our config looks like this

    And all the code is in build/ninja* of the same repo

  • P Language
    3 projects | | 6 Jan 2023
    I watched this a few weeks ago, great talk and exciting tool!

    Can you expand on this answer about whether the generated code is run in production or not?

    I would expect that generating USB drivers is just as demanding from a performance perspective as cloud services? You have generally have better and more control over hardware in the latter case?

    Do you know if the P-generated code is still used for USB drivers, or if they moved away from that approach and just use the modeling process?

    The state machines seem pretty low level, so I don't understand in principle why efficient code couldn't be generated from them?

    FWIW I'm using 3 or 4 C/C++ code generators for, and I've the layer of indirection useful in many ways (although it also can make it harder for people to understand)

  • Ask HN: Who is hiring? (January 2023)
    12 projects | | 2 Jan 2023
    Oil Shell | C++ / Python Language Engineer | Remote (e.g. Canada, Europe), Flexible, Open Source |

    I have a slightly unusual job funded by a grant under ! Everything is flexible -- think of it as an open source project where you happen to get paid.

    We started in June, and there are currently 2 part-time contributors. We can use more help!

    The job is to work on a C++/Python shell interpreter with a garbage-collected runtime. Depending on your interest, you can work on:

    (1) Data-structure heavy, performance-sensitive C++ code -- e.g. mark bitmaps for the GC, small value optimization, lazy sweeping, hash tables, and more. We have an objective goal that enables creativity: make the shell as fast as bash. Currently it's 1.6x slower on a long batch workload.

    This runtime will let us add real data structures and JSON to a shell! ( )

    (2) Semi-automatically translating code from typed Python to C++. This can be simple (adding MyPy types) or involved (compiling Python's yield to state machines)

    (3) Benchmarks, builds, testing -- I like automating everything, and shell works great here :)

    We've made great progress lately -- here's a screencast of our custom ~6000 line garbage-collected runtime working on real code (note GC debug output): (this worked as of 11 days ago, detailed blog post upcoming)

    Some background: A Garbage-Collected Heap in C++, Shaped Like Typed Python (and more on the blog)

    Everything about the project is open, so please take a look and contact me at [email protected] if interested. We can chat online or do a video call (I'm based in the USA). We can also arrange a code walkthrough or PAID "trial period". We want people who will have fun working on these problems.

    Compensation: First grant was for 50K euros, and a potential second grant would be for 50K, to be split up among contributors. -- We now have a fast and flexible Ninja build, as well as a comprehensive CI that keeps the master branch green

    Contact: [email protected]

    12 projects | | 2 Jan 2023
    Thanks! There's definitely room for people with a wide variety of skills, e.g. just shell or just Python. Feel free to chime in on Github, Zulip, reddit, etc.! (all links on the home page
  • A portable, modern regular expression language
    9 projects | | 30 Dec 2022
    FWIW here is a list of other such projects:
  • Like seriously why does not one does it ?
    15 projects | | 17 Dec 2022
    The Oil language is a very interesting project whose author clearly recognizes both the benefits and the weaknesses of POSIX shells. This post describes major improvements that can only be made by breaking POSIX compliance (again, like Bash, via modes/options); but more relevant to my criticism of existing POSIX-compliant shells is this in-depth post about arrays, which argues that the core data type for shells should have been array-of-strings rather than string. I completely agree with this premise, and I think that the need for tools like find to include an option (-print0) for splitting output using null characters rather than newlines just shows how inadequate ASCII is as a global datatype for a glue language like the shell.
  • Pointer Compression in Oilpan
    2 projects | | 29 Nov 2022
    FWIW I recently tried this on, thinking the code would be faster due to better cache locality. There are many pointer rich data structures and they should be packed much more tightly when pointers are 32 bit.

    It definitely saved memory, but it was slightly slower or the same speed. My guess is that 32-bit performance isn't prioritized on x86-64 by either compiler writers or chip designers, i.e. they optimize the common case of 64 bit pointers.

    Definitely interested in other comments / opinions / data on this.

    I think if it actually sped programs up, you would see many more distros compiling packages for 32-bit. It does save memory, but somehow that's not big enough motivation. Probably because desktops/laptops have a lot of memory, and Linux systems with constrained memory are probably already 32-bit.

    And because real memory hogs like browsers probably want to address more than 4GB. Though to be honest I think a multi-process browser with a 4GB-per-origin limit sounds like a very good idea!

What are some alternatives?

When comparing nushell and oil you can also consider the following projects:

fish-shell - The user-friendly command line shell.

starship - ☄🌌️ The minimal, blazing-fast, and infinitely customizable prompt for any shell!

elvish - Elvish = Expressive Programming Language + Versatile Interactive Shell

PowerShell - PowerShell for every system!

xonsh - :shell: Python-powered, cross-platform, Unix-gazing shell

volta - Volta: JS Toolchains as Code. ⚡

alacritty - A cross-platform, OpenGL terminal emulator.

jq - Command-line JSON processor

nvim-nu - Basic editor support for the nushell language