Bash-like $SHELL designed for greater commandline productivity and safer shell scripts (by lmorg)

Murex Alternatives

Similar projects and alternatives to murex

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

Suggest an alternative to murex

Reviews and mentions

Posts with mentions or reviews of murex. We have used some of these posts to build our list of alternatives and similar projects. The last one was on 2022-01-16.
  • Gokrazy – A Native Go Userland
    6 projects | | 16 Jan 2022
    If it is any help, I've written a $SHELL in Go and have been using it as my primary shell for around 5 years now.

    It's intentionally not designed to be a drop in replacement for Bash though. I saw no point replicating all of the problems with Bash when writing a new shell. So it does a lot of things different -- better in most cases -- but that does also create a learning curve too (I mean you're literally learning a new language).

  • Unix Shell Programming: The Next 50 Years
    7 projects | | 18 Dec 2021
  • Command Palettes: How Typing Commands Became the Norm Again
    12 projects | | 28 Nov 2021
  • Bash Patterns I Use Weekly
    4 projects | | 23 Nov 2021
  • Bash functions are better than I thought
    23 projects | | 31 Oct 2021
    murex author here. Hopefully I can answer some questions:

    > I do scan alternative shells from time to time. I could have missed but I didn't see multiple dispatch in any of them. Which ones have it? Just to clarify: In which shell you can define several methods with the same name and when called, the method to invoke is selected based on the types of the arguments?

    I've not heard of the term "multiple dispatch" but reading the thread it sounds like you're describing function overloading. Powershell does support this with classes[0].

    murex does it's overloading at the API level[1]. The reason behind that decision is to keep the methods simple (eg a pipeline might contain JSON or CSV data but you as a shell user don't want to run into situations where you've written a function that supports one data type but not another. So murex automatically abstracts that part away for you. In addition to the point laumars mentioned about consistent `jq`-like methods that are data type agnostic, it allows for easy iteration (eg `open somedata -> foreach { do stuff }` -- where you don't need to think about data types, murex does the heavy lifting for you).

    There are some specific builtins that support "overloading" of sorts but instead of "overloading" they have handlers[2][3]

    It's also worth adding that function overloading is supported in the same way that its also supported in Bash too where you might have a function but if there is a alias of the same name that will take priority. There are also private[4] functions (which are namespaced) so you have additional controls to avoid accidental overloading when writing modules too.

    > I did not even see how to define named parameters -

    Named parameters are optional because neither Windows nor POSIX have any understanding of named arguments in their processes. I did consider abstracting that into murex's functions regardless like Python et al would but I couldn't design a way that wasn't jarring nor cumbersome to write in a hurry nor worked transparently with Windows and POSIX ARGS[]. So I've come up with an optional builtin called `args`[5] which allows you to define flags, which are effectively the same thing as named parameters except they're supported natively by Windows and POSIX ARGS[], so you can write a murex script as a native shell script without leaving the user to write another abstraction layer themselves interpreting an indexed argument into an named arguments. You can write really quick Bash-like functions or more verbose scripting style functions too.

    > Examples of things in NGS that I have not seen anywhere else: syntax for run-command-and-parse-output, proper handling of exit codes.

    Both of these are baked into murex as well. The run-command-and-parse-output is the API stuff mentioned above. It's where the overloading happens.

    As for error handling: any command is considered a failure if there is either a non-zero exit code, STDERR contains a failed message (eg "false", "failed", etc) or STDERR is > STDOUT[6]. This has covered every use case I've come across.

    Additionally STDERR is highlighted red by default and when a process fails you're given a mini-stack trace showing where in the script the error happened. You have try/catch blocks, saner if syntax etc that all use the same API for detecting if a process has failed too.

    The other thing murex does is have a testing framework baked into the shell. The docs for test[7] need expanding though. But in essence:

    - you can write proper unit tests

    - you can intercept STDOUT (even if it's mid pipeline) and test that output. This works around instances where (1) you can't have full on unit tests due to side effects in a function that can't be easily mocked (2) you want to add your own debugging routines (rather than just printing values to STDOUT)

    - you can add state watches (except in murex, the watches are Turing complete so you're not just adding noise to your terminal output but can put meaningful debug messages).

    And all of the debugging stuff can be written straight into your normal shell routines and cause no additional execution overhead unless you've purposely enabled test mode.

    So yeah, I've spent a significant amount of time designing smarter ways of handling failures than your average shell scripting language.

    > Regarding exit codes. Typical approach to exit codes varies. Python - "I don't care, the programmer should handle it". Some Python libraries and other places - "Non-zero is an error". That's simplistic and does not reflect the reality in which some utilities return 1 for "false". bash (and probably other shells too) is unable to handle in a straightforward manner situation where external command can return exit codes for "true", "false" and "error". It just doesn't fit in the "if" with two branches. NGS does handle it with "if" with two branches + possible exception thrown for "error" exit code.

    If you're describing that as a "two branch" approach then technically murex could be argued as having "three branches" because it checks exit code, STDERR contents, and payload size too. Personally I just describe it as "error handling" because in my view this is how peoples expectations are rather than the reality of handling forked executables.

    I guess where NGS and murex really differ is NGS likes to expose its smart features whereas in murex they're abstracted away a little (they can still be altered, customised, etc) to keep the daily mundane shell usage as KISS (keep it simple stupid) as possible. eg you can overload function calls if you really wanted but that can often cause unforeseen complications or other unexpected annoyances right when you least want it to. So murex keeps that stuff around for when you need it but finds ways to avoid people needing to rely on it.

    > NGS knows that some external programs have exit code 1 which does not signify an error.

    Having different behaviours for different executables hard coded into the shell is one behaviour I purposely avoided. I do completely understand why incentive behind wanting to do this and wouldn't criticise others for doing that but given external programs can change without the shell being aware, they can be overloaded with aliases, functions, etc, and they might even just differ between Linux, BSD, Windows, etc -- well it just seemed like it causes more issues than it solves. You also then run into problems where users expect the shell to understand all external executables but there are some you haven't anticipated. Ultimately it creates a kind of special magic that is unpredictable and outside the control of the shell itself. So instead I've relied on having foundational logic that is consistent. It's the one side of shell programming where I've placed the responsibility onto the developer to get right rather than automagically doing what I think they are expecting.




    [2] &&

    [3] (I need to write a lot more documentation around event driving programming in murex)





  • TV is a cross-platform CSV pretty printer made to maximize viewer enjoyment
    19 projects | | 27 Sep 2021
    Shameless plug, but so does my shell,

      $ open test/example.csv | format generic
  • Bringing the Unix Philosophy to the 21st Century
    11 projects | | 22 Aug 2021
    This is why I wrote murex shell (, it's an alternative $SHELL, so you'd use it in place of Bash or Zsh, but it's optimised for modern DevOps tools. Which means JSON and YAML are first class citizens.

    It's syntax isn't 100% POSIX compatible so there is some new stuff to learn but it works with all the existing POSIX tools and is more readable than AWK and Perl but while also being terse enough to write one liners.

  • Command Line Tools for Productive Programmers
    17 projects | | 28 Jul 2021
    There'll always be multiple ways to skin the proverbial cat.

    Shameless plug but I'd written my own $SHELL callewd `murex` as I kept running into pain points with Bash as a DevOps engineer. The shell doesn't have `tree` inbuilt but it does have FZF-like navigation built in.

    I've been using it as my primary shell for a few years now and I'm not going to pretend that it isn't BETA it does work. However it's not POSIX and some of the design decisions might rub people the wrong way (given how opinionated peoples work-flows are). But if you're curious then check it out.

  • nushell - A new type of shell
    9 projects | | 16 Jun 2021
  • Unix Shell Programming: The Next 50 Years [pdf]
    11 projects | | 4 Jun 2021
  • The Dawn of a New Command Line Interface
    3 projects | | 13 Apr 2021
    This is something I've been working on with my shell,

    The problem isn't so much finding a way of passing metadata but how do you retain compatibility with existing GNU / UNIX tools? It would be easy to create an entirely new shell (like Powershell) that throws out backwards compatibility but that wouldn't be very practical on Linux/UNIX when so much of it is powered by old POSIX standards.

    I addressed this by having a wrapper around pipes. Anything that connects out to a classic executable is a traditional POSIX byte stream with no type data sent. Anything sent to a command that is written to support my shell can make use of said meta data.

    As for handling graphical components, that's a little easier. Many command line programs already alter their behaviour depending on whether STDOUT is a TTY or not. I take things a little further and have a media handler function, called `open`, that inlines stuff in a shell that can be (it will render images in the terminal) but if STDOUT is a TTY then it will pipe the image data instead.

  • What was the point of [ “x$var” = “xval” ]?
    11 projects | | 12 Apr 2021
    `if` and iterations were two things that annoyed me about bash enough to write my own $SHELL. It's not a transpiler though so I can't realistically use it for production services. However for quickly hacking stuff together for testing / personal use it's been a life saver due to having the same prototyping speed of bash but without the painful edge cases.

    Not suggesting it's suitable for everyone though. But it's certainly solved a lot of problems for me.

    11 projects | | 12 Apr 2021
    It's worth adding mine to the list too:


    Superficially it's quite similar to elvish (purely by coincidence) but it's aimed around local machine use (eg by developers and devops engineers) so is as much inspired by IDEs as it is by shells.

    11 projects | | 12 Apr 2021
    I've written one specifically to solve if and looping: (docs:

    Others I've not used are oil shell, which aims to be a better Bash. Elvish, which has a heck of a lot of similarities with my own project (and is arguably more mature too). There's shells in LISP, Python and all sorts.

    So there are options out there

  • Is there a CLI you're missing?
    6 projects | | 18 Mar 2021
    I've gotten into Murex recently and I really like it. It's a bit of a learning curve if you're coming from bash/zsh (like I was) but it's not too bad and I think its syntax makes a lot more sense than bash/zsh.


Basic murex repo stats
6 days ago

lmorg/murex is an open source project licensed under GNU General Public License v3.0 only which is an OSI approved license.

Static code analysis for 29 languages.
Your projects are multi-language. So is SonarQube analysis. Find Bugs, Vulnerabilities, Security Hotspots, and Code Smells so you can release quality code every time. Get started analyzing your projects today for free.
Find remote Go jobs at our new job board There are 5 new remote jobs listed recently.
Are you hiring? Post a new remote job listing for free.