HackerReposA FIELD GUIDE TO OPEN SOURCE
ProSponsor the shelf♧ 0
← Back to top all-time
lmorg
murex
Go2017–2025
lmorg / murex

murex

A smarter shell and scripting environment with advanced features designed for usability, safety and productivity (eg smarter DevOps tooling)

8Distinct people
68Mentions
0Explicit recommenders
1.9KGitHub stars
REPOSITORY AT A GLANCE

What to know before exploring

What it is

A smarter shell and scripting environment with advanced features designed for usability, safety and productivity (eg smarter DevOps tooling)

GitHub

Where it is used

No documented product use has been verified yet.

What people are saying

No recommendation phrase was found in the indexed comments.

No classified warning is attached to this page. Read the discussions before treating silence as approval.

Also in these discussions

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

This week on Hacker News

Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 3:56:07 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 year68 dated mentions

Observed mentions: 2017-04-24 08:16:39 UTC to 2025-09-30 16:15:26 UTC.

051015202017-01-01 00:00:00 UTC to 2018-01-01 00:00:00 UTC (exclusive): 6 mentions; 2 submissions, 4 comments20172018-01-01 00:00:00 UTC to 2019-01-01 00:00:00 UTC (exclusive): 5 mentions; 0 submissions, 5 comments2019-01-01 00:00:00 UTC to 2020-01-01 00:00:00 UTC (exclusive): 2 mentions; 0 submissions, 2 comments2020-01-01 00:00:00 UTC to 2021-01-01 00:00:00 UTC (exclusive): 7 mentions; 0 submissions, 7 comments2021-01-01 00:00:00 UTC to 2022-01-01 00:00:00 UTC (exclusive): 20 mentions; 1 submissions, 19 comments20212022-01-01 00:00:00 UTC to 2023-01-01 00:00:00 UTC (exclusive): 11 mentions; 0 submissions, 11 comments2023-01-01 00:00:00 UTC to 2024-01-01 00:00:00 UTC (exclusive): 10 mentions; 1 submissions, 9 comments2024-01-01 00:00:00 UTC to 2025-01-01 00:00:00 UTC (exclusive): 2 mentions; 0 submissions, 2 comments2025-01-01 00:00:00 UTC to 2026-01-01 00:00:00 UTC (exclusive): 5 mentions; 0 submissions, 5 comments2025

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.
PeriodStart (UTC)End (exclusive, UTC)MentionsSubmissionsComments
20172017-01-01 00:00:00 UTC2018-01-01 00:00:00 UTC624
20182018-01-01 00:00:00 UTC2019-01-01 00:00:00 UTC505
20192019-01-01 00:00:00 UTC2020-01-01 00:00:00 UTC202
20202020-01-01 00:00:00 UTC2021-01-01 00:00:00 UTC707
20212021-01-01 00:00:00 UTC2022-01-01 00:00:00 UTC20119
20222022-01-01 00:00:00 UTC2023-01-01 00:00:00 UTC11011
20232023-01-01 00:00:00 UTC2024-01-01 00:00:00 UTC1019
20242024-01-01 00:00:00 UTC2025-01-01 00:00:00 UTC202
20252025-01-01 00:00:00 UTC2026-01-01 00:00:00 UTC505

What Hacker News says

68 sources
> the challenges in go is a reference to a discussion in the elvish chat where one participant claimed that go's os.StartProcess() API makes it impossible to implement unix job control with 100% fidelity. That's not true. os.StartProcess() takes a pointer to https://pkg.go.dev/os#ProcAttr which then takes a pointer to https://pkg.go.dev/syscall#SysProcAttr If I recall correctly, either Setctty or Foreground needs to be set to true (I forget which offhand, possibly Foreground, but browsing the StartProcess()'s source should reveal that. I don't actually do that in Murex, because I want to add additional hooks to SIGSTSP and I can't do that if I hand ownership of the TTY to the child process. https://github.com/lmorg/murex/blob/master/lang/exec_unix.go... But that means that some tools like Helix then break job control in Murex because they
Read the rest
don't think Murex supports job control (due to processes being marked non-traditionally). You can see higher up in that file above where I need to force Murex to take ownership of the TTY again as part of the process clean up. (line 28 onwards) Processes invoked from a shell should also be part of a process group: https://github.com/lmorg/murex/blob/master/lang/exec_unix.go... You also need to set the shell to be a process session leader: https://github.com/lmorg/murex/blob/master/shell/session/ses... All of this is UNIX (inc Linux) specific so you can see compiler directives at the top of those files to exclude WASM, Windows, and Plan 9 builds. I don't even try to emulate job control on those platforms because it's too much effort to write, test, and maintain. > i have been wondering if it is not possible to get rid of that emulation layer and provide for a more rich way for programs to interact with the user. Funny enough, this is something I'm experimenting with my terminal emulator, though it's very alpha at the moment https://github.com/lmorg/Ttyphoon > to get that emulation layer we only need to port something like tmux onto that new api My terminal emulator does exactly this. It uses tmux control mode so that tmux manages the TTY sessions and the terminal emulator handles the rendering. > https://github.com/yshui/job-security so this can be done without having to reimplement the emulation yet again The problem with a 3rd party tool for job control is that it doesn't work with shell builtins. And the massive value add for shells like Murex and Elvish is their builtins. This is another reason why I didn't want POSIX job control in Murex: I wanted to keep my shell builtins powerful but also allow them to support job control in a way that feels native and transparent to the casual user.
In Elvish – Scripting language and interactive shell
> I can't tell if it's irony or not given the sentiment in this thread, but that is not a declaration of a multiline Description field, that's a field of User named "Description:>-" that happens to be missing its trailing ":" The trailing ‘:’ was there right after the ‘n’. Examples of this syntax: https://github.com/lmorg/murex/blob/master/builtins/core/arr... I do agree it’s a bit of a kludge. But if you want data types and unquoted strings then anything you do to the syntax to denote strings over other data types then becomes a bit of a kludge. The one good thing about this kludge is it allows for string literals (ie no complicated escaping rules). > Seeing that used systemically, versus just for "risky" fields makes me want to draw attention to the fantastic remarshal tool[1], which offers a "--yaml-style >" (and "|" and the rest) whic
Read the rest
h will render yaml fields quoted as one wishes I don’t really understand what you’re alluding to here.
In YAML: The Norway Problem (2022)
I have authored a shell in Go and while it doesn’t aim to replace coreutils, it does have a decent number of builtins as part of its application. So in theory I could build a feature that allows you to ship a self contained executable like you’ve described. If this is something you’re genuinely interested in and my shell has the right kind of ergonomics for you, then feel free to leave a feature request: https://github.com/lmorg/murex
In Bunster: Compile bash scripts to self contained executables
Stable is a problem because a lot of these shells don’t offer any guarantees for breaking changes. My own shell, https://github.com/lmorg/murex is committed to backwards compatibility but even here, there are occasional changes made that might break backwards compatibility. Though I do push back on such changes as much as possible, to the extent that most of my scripts from 5 years ago still run unmodified. In fact I’ve started using some of those older scripts as part of the automated test suits to check against accidental breaking changes.
In The case for Nushell
I cannot claim to have tested every ZWJ character on every terminal emulator but if you find any ZWJ related bugs in murex shell https://GitHub.com/lmorg/murex then it will be treated as a serious bug because Murex does have international users so aims for greater compatibility with other language writing systems (albeit the documentation is presently only available in English).
In Terminal Support for Emoji
Murex (https://GitHub.com/lmorg/murex) doesn’t replace coreutils with builtins but manages interop with commands just fine. Most output is relatively easy to parse, sometimes you need to annotate the pipe with what format to expect but that’s easy enough to do. And Murex does come with builtins that cover some of the more common coreutils use cases for instances when you want greater assurances of the quality of the data - but those are named differently to their coreutil counterparts to avoid confusion.
In Dt: Duck tape for your Unix pipes
> Did not realize that POSIX after it was obsolete standardized commands ;) anyway. POSIX does standardise some commands[0], albeit not many and good few of them are implemented as builtins even in Bash. But it also defines STDOUT (etc) files. The way Powershell passes data is as .NET objects. The way Murex passes data is as POSIX byte streams but with type annotations passed out of band. This creates some extra overhead in serialising data but the advantage is that it works with all of your existing tooling without modification. > Do you write articles about how you make coreutils output structured? Is that a command specific adapter or how does that work? I haven't but that's a good idea. The way it works is just that you add type annotations. The default type is assumed text data, potentially in columns, like you'd see from `ps aux` or
Read the rest
`ls -l`. There are also some builtins (eg [1][2]) that are data type aware. So if you just use the most basic features of Murex, you get a few footguns removed (eg by default variables containing spaces don't get split into multiple parameters) and a slightly different syntax to Bash but all the same CLI tools work. However if you want to invest more into Murex then you get greater power from it eg the ability to inline SQL queries[3], write unit tests[4], better error handling[5][6], etc as well as being able to do `jq` like expressions against a multitude of object and table formats. I really do need to get better at publishing it's features though! [0] https://en.wikipedia.org/wiki/File:POSIX_Utilities.pdf [1] https://murex.rocks/docs/commands/index.html & https://github.com/lmorg/murex/blob/master/examples/table-in... [2] https://murex.rocks/docs/commands/foreach.html [3] https://github.com/lmorg/murex/blob/master/examples/inline-s... [4] https://github.com/lmorg/murex/blob/master/config/defaults/p... [5] https://murex.rocks/docs/commands/runmode.html [6] https://github.com/lmorg/murex/blob/master/examples/try-catc...
In Show HN: A smarter Unix shell and scripting environment
This is similar to how my shell works. It still just passes bytes around but additionally passes information about how those bytes could be interpreted. A schema if you will. So it works as cleanly with POSIX / GNU / et al tools as it does with fancy JSON, YAML, CSV and other document formats. It basically sits somewhere between Powershell and Bash: typed pipelines like Powershell but without sacrificing familiarity with all the CLI commands you already use day in and day out. https://github.com/lmorg/murex As an aside, I’m about to drop a massive update in the next few days that will make the shell even more intuitive to use.
In Nushell.sh ls | where size > 10mb | sort-by modified

Showing the 15 most recent of 68 sources. Enable JavaScript to search and browse every indexed mention.

MAKE YOURSELF AT HOME

A few shortcuts

/
Search the collection
?
Open this guide
Esc
Close dialogs and navigation

Your saved repositories and interests stay in this browser.