oil

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)

Oil Alternatives

Similar projects and alternatives to oil

  • nushell

    oil VS nushell

    A new type of shell

  • ngs

    oil VS ngs

    Next Generation Shell (NGS)

  • InfluxDB

    Build time-series-based applications quickly and at scale.. InfluxDB is the Time Series Platform where developers build real-time applications for analytics, IoT and cloud-native services. Easy to start, it is available in the cloud or on-premises.

  • fish-shell

    oil VS fish-shell

    The user-friendly command line shell.

  • murex

    oil VS murex

    Bash-like shell and scripting environment with advanced features designed for safety and productivity (eg smarter DevOps tooling)

  • ShellCheck

    oil VS ShellCheck

    ShellCheck, a static analysis tool for shell scripts

  • xonsh

    oil VS xonsh

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

  • elvish

    oil VS elvish

    Elvish = Expressive Programming Language + Versatile Interactive Shell

  • Sonar

    Write Clean Python Code. Always.. Sonar helps you commit clean code every time. With over 225 unique rules to find Python bugs, code smells & vulnerabilities, Sonar finds the issues while you focus on the work.

  • zig

    oil VS zig

    General-purpose programming language and toolchain for maintaining robust, optimal, and reusable software.

  • shite

    oil VS shite

    The little hot-reloadin' static site maker from shell.

  • PowerShell

    oil VS PowerShell

    PowerShell for every system!

  • ohmyzsh

    oil VS ohmyzsh

    🙃 A delightful community-driven (with 2,100+ contributors) framework for managing your zsh configuration. Includes 300+ optional plugins (rails, git, macOS, hub, docker, homebrew, node, php, python, etc), 140+ themes to spice up your morning, and an auto-update tool so that makes it easy to keep up with the latest updates from the community.

  • melody

    oil VS melody

    Melody is a language that compiles to regular expressions and aims to be more easily readable and maintainable

  • pomsky

    oil VS pomsky

    A new, portable, regular expression language

  • zx

    oil VS zx

    A tool for writing better scripts

  • just

    oil VS just

    🤖 Just a command runner

  • RegExr

    oil VS RegExr

    RegExr is a HTML/JS based tool for creating, testing, and learning about Regular Expressions.

  • aero

    oil VS aero

    Aero is a new modern, experimental, unix-like operating system following the monolithic kernel design. Supporting modern PC features such as long mode, 5-level paging, and SMP (multicore), to name a few. (by Andy-Python-Programmer)

  • libxo

    oil VS libxo

    The libxo library allows an application to generate text, XML, JSON, and HTML output using a common set of function calls. The application decides at run time which output style should be produced.

  • kleenexp

    oil VS kleenexp

    modern regular expression syntax everywhere with a painless upgrade path

  • SaaSHub

    SaaSHub - Software Alternatives and Reviews. SaaSHub helps you find the best software and product alternatives

NOTE: The number of mentions on this list indicates mentions on common posts plus user suggested alternatives. Hence, a higher number means a better oil alternative or higher similarity.

oil reviews and mentions

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 | news.ycombinator.com | 23 Jan 2023
    Nice! I also use inotifywait for hot reload when writing https://www.oilshell.org/

    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 | news.ycombinator.com | 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 https://www.oilshell.org/ -- 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 | news.ycombinator.com | 12 Jan 2023
    https://news.ycombinator.com/item?id=34291191 )

    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: https://old.reddit.com/r/oilshell/comments/109t7os/pictures_...

    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. https://github.com/oilshell/oil/wiki/Compact-AST-Representat...

  • Why Use Make
    10 projects | news.ycombinator.com | 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

    https://github.com/stb-tester/apt2ostree

    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

    https://github.com/oilshell/oil/blob/master/core/NINJA_subgr...

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

  • P Language
    3 projects | news.ycombinator.com | 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?

    https://youtu.be/5YjsSDDWFDY?t=2200

    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 https://www.oilshell.org, 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 | news.ycombinator.com | 2 Jan 2023
    Oil Shell | C++ / Python Language Engineer | Remote (e.g. Canada, Europe), Flexible, Open Source | https://oilshell.org

    I have a slightly unusual job funded by a grant under https://nlnet.nl ! 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! ( http://www.oilshell.org/blog/2021/01/why-a-new-shell.html )

    (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):

    https://asciinema.org/a/547312?t=30 (this worked as of 11 days ago, detailed blog post upcoming)

    Some background: A Garbage-Collected Heap in C++, Shaped Like Typed Python

    https://www.oilshell.org/blog/2022/05/gc-heap.html (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.

    https://github.com/oilshell/oil/wiki/Where-Contributors-Have... -- 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 | news.ycombinator.com | 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 https://www.oilshell.org)
  • A portable, modern regular expression language
    9 projects | news.ycombinator.com | 30 Dec 2022
    FWIW here is a list of other such projects: https://github.com/oilshell/oil/wiki/Alternative-Regex-Synta...
  • Like seriously why does not one does it ?
    15 projects | reddit.com/r/ProgrammerHumor | 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 | news.ycombinator.com | 29 Nov 2022
    FWIW I recently tried this on https://www.oilshell.org, 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!

  • A note from our sponsor - Sonar
    www.sonarsource.com | 30 Jan 2023
    Sonar helps you commit clean code every time. With over 225 unique rules to find Python bugs, code smells & vulnerabilities, Sonar finds the issues while you focus on the work. Learn more →

Stats

Basic oil repo stats
194
2,445
9.2
1 day ago
SaaSHub - Software Alternatives and Reviews
SaaSHub helps you find the best software and product alternatives
www.saashub.com