Bashforth VS oil

Compare Bashforth vs oil and see what are their differences.


A Forth interpreter, entirely written as bash script. But by now is yoda ( the better bashforth. (by Bushmills)


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
  • SonarQube - Static code analysis for 29 languages.
  • Scout APM - Less time debugging, more time building
  • SaaSHub - Software Alternatives and Reviews
Bashforth oil
4 167
58 2,226
- 1.5%
3.1 9.7
7 months ago 4 days ago
Shell Python
GNU General Public License v3.0 or later 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 Bashforth. We have used some of these posts to build our list of alternatives and similar projects. The last one was on 2022-01-08.


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 2022-08-07.
  • Using Landlock to Sandbox GNU Make
    10 projects | | 7 Aug 2022
    The 3 makefiles I wrote were actually for a medium-size open source project (measured by lines of code)

    For two of the Makefiles I needed to enumerate the rules dynamically (inputs weren't fixed, they were "globbed"), and my memory is that this interacted very poorly with other features build variants

    Whereas those pattern are extremely simple with Python/Ninja. Just write a loop or a nested loop and generate a build rule each time. Done in 5 minutes whereas GNU make was a constant struggle.

  • Oil Shell
    1 project | | 1 Aug 2022
  • A Tutorial on Portable Makefiles
    9 projects | | 1 Aug 2022
    The variants control the compile and link flags:

    Overall this is the best build system I've used :) My pet peeve is having to clean when changing the variant.

    I'm sure it's reinventing some of the 120K lines of CMakeLists.txt that comes with CMake, but I don't have to learn and debug a wonky shell-ish language!

    One downside is that you probably don't want to invoke shell on Windows. I find that very useful though, so I'm not sure what would replace it on Windows. (I guess batch files, but I don't think they're powerful enough)

  • Oil 0.11.0 - Big Features and Project Changes
    1 project | | 31 Jul 2022
  • Public Domain Posix Make
    4 projects | | 31 Jul 2022
    Yeah I'm left scratching my head at the purpose of this project.

    I wrote 3 GNU makefiles from scratch (a few hundred lines each) starting in ~2016 for, and regret it. I switched to Python + Ninja, and I should have just used that all along.

    So I think GNU make is already pretty old and regretted, and POSIX make even more so.

    CMake + Ninja seems be pretty common these days, but for my project Python works fine. CMake is also a bad (shell-like) language, but I'm pretty sure it's better and more featureful than GNU make (i.e. you're less likely to need to switch build systems/languages due to a new requirement)

    This thread has some interesting experiences ... it does seem like there needs to be a better high level language to generate Ninja

  • Survey of Config Languages
    1 project | | 31 Jul 2022
  • Two Years and over 700 Websites Later
    2 projects | | 18 Jul 2022
    Yeah I thought that was 1 MB per SITE, but it's 1 MB per PAGE which is WAY too big! I don't want to load that on my phone

    I just checked and my home page is 3,575 bytes, which is 280x smaller than 1 MB:

        $ curl | wc --bytes
  • What are the disadvantages of using an interactive shell based on a regular programming language (python, scheme's scsh, etc) vs. bourne shell and bash?
    5 projects | | 17 Jul 2022
    There also exist modern shells that look more like general purpose languages, such as nushell and oil.
  • The Dhall Configuration Language
    21 projects | | 14 Jul 2022
    Comparison of similar projects, including Dhall:

  • Websites Die
    3 projects | | 29 Jun 2022
    Hm interesting, I read over your 7 guidelines [1] and I would say I agree 50%.

    So the most lightweight way to keep something up and running is to make it trivial to port to many hosting configurations by simplifying the toolchain needed to rehost it -- I agree with this, although to me I would use the words "standards" and multiple implementations. The linked article doesn't appear to emphasize this.

    - Return to vanilla HTML/CSS

    Again I feel the relevant issue is "standards", multiple implementations, and the fallback option of "old code" like GNU coreutils (i.e. taking advantage of the Lindy Effect). Not just just HTML/CSS (which certainly meet all of those criteria.)

    I thought about this when designing and the toolchain

    - The site started in Markdown but is now standardized on CommonMark [1], which has multiple implementations. So I don't see any reason to stick to HTML/CSS.

    - The tools are written in Python and shell [2]. Both languages have multiple implementations. (Ironically, Oil is a second implementation of bash! My bash scripts run under both bash and Oil.)

    - Python and shell rely on Unix, which is standardized (e.g. Linux and FreeBSD have a large common subset that can build my site).

    This is perhaps unconventional, but I avoided using languages that I don't know how to bootstrap like node.js (has a complex JIT and build process), Go (doesn't use libc) or Rust (complex bootstrap).

    On the other hand, C has multiple implementations, and Python and shell are written in C, and easy to compile. I'd say Lua also falls in this category, but node.js doesn't.

    I feel like this is at least 60% of the way to making a website that lasts 30 years. The other 40% is the domain name and hosting.

    This is a pretty a big site now, you can tar a lot of it up and browse it locally (well it's true you may have to rewrite some self links).

    Of course, this is my solution as a technical user. If you're trying to solve this problem for the general public, then that's much harder.



    - Don't minimize that HTML

    Mildly agree if only because it's useful to be able to read HTML to rewrite self links and so forth. Tools don't need it, but it's nice for humans.

    - Prefer one page over several

    If you're allowed to use Python and shell to automate stuff, then this isn't an issue. I suppose another risk is that people besides me might not understand how to maintain my code. But I don't think it needs to be maintained -- I think it will run forever on the basis of Unix, shell, and Python. Those technologies have "crossed the chasm", where again I think the jury is still out on others.

    - End all forms of hotlinking

    Yes, my site hosts all its own JS and CSS.

    - Stick with native fonts

    Yes, custom fonts have a higher chance of being unreadable in the future. I just use the browser's font preference to avoid this issue. It's more future proof and in keeping with the spirit of the web (semantic, not pixel perfect).

    - Obsessively compress your images


    - Eliminate the broken URL risk

    I think too few people are using commodity shared hosting ... I've been meaning to write some blog posts about that. I use Dreamhost but NearlyFreeSpeech is basically the same idea. It's basically a Unix box and a web server that somebody else maintains.

    The key point is that it has multiple implementations. It is a de facto standard. The main difference between a tarball of HTML and a shared hosting site is that say "index.html" is always respected as the root.

    So I expect Heroku and similar platforms to come and go, but the de-facto standard of a shared hosting interface will stay forever. It's basically any Unix + any static web server, e.g. I think OpenBSD has a pretty good httpd that's like Apache/Nginx for all the relevant purposes.

    So I guess this is adding sort of a programmer's slant to it. To be honest it took me a long time to be fluent enough in Python and shell to make a decent website :) Markdown/CommonMark definitely helps too. I had of course made HTML before this, but it was the odd page here and there. Making a whole site does require some automation, and I agree that lots of common/popular tools and hosting platforms will rot very quickly. (and like you I've seen that happen multiple times in my life!)

What are some alternatives?

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

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

nushell - A new type of shell

elvish - Elvish = Expressive Programming Language + Versatile Interactive Shell

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

ShellCheck - ShellCheck, a static analysis tool for shell scripts

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

PowerShell - PowerShell for every system! - Source code for Includes browser testing code and site rendering. - Bash Line Editor―a full-featured line editor written in pure Bash! Syntax highlighting, auto suggestions, vim modes, etc. are available in Bash interactive sessions!

ngs - Next Generation Shell (NGS)

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.

ohmyzsh - 🙃 A delightful community-driven (with 2,000+ 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.