Murex Alternatives

murex reviews and mentions

• VanadiumOS: Portable, multi-user Unix-like OS
  4 projects | news.ycombinator.com | 9 Jan 2023

  It's possible without any kernel changes. My shell (https://github.com/lmorg/murex) already supports doing that.

  The way it works is it uses fd3 to communicate schema information so it can natively support all the existing "dumb" pipes without any modification but any new tools can be written to send objects instead (albeit byte encoded).

  It's not as elegant as PowerShell sending .NET objects natively, but then PowerShell doesn't work with existing CLI tools natively (it needs wrapper scripts to convert them into PowerShell commands). Whereas my shell is fully backwards compatible while still supporting a suite of additional functionality too.

• Shell Script Best Practices, from a decade of scripting things
  19 projects | news.ycombinator.com | 27 Oct 2022

  > getting the shell quoting hell right

  Shameless plug coming, it this has been a pain point for me too. I found the issue with quotes (in most languages, but particularly in Bash et al) is that the same character is used to close the quote as is used to open it.m. So in my own shell I added support to use parentheses as quotes in addition to the single and double quotation ASCII symbols. This then allows you to nest quotation marks.

  https://murex.rocks/docs/parser/brace-quote.html

  You also don’t need to worry about quoting variables as variables are expanded to an argv[] item rather than expanded out to a command line and then any spaces converted into new argv[]s (or in layman’s terms, variables behave like you’d expect variables to behave).

  https://github.com/lmorg/murex

• Enter a command to see help text for each arg
  4 projects | news.ycombinator.com | 30 May 2022

  Some shells have this built in, like Fish and my own one ( https://murex.rocks ) too

• Everything you ever wanted to know about terminals(but were afraid to ask)
  14 projects | news.ycombinator.com | 17 May 2022
• Guide: Hush Shell-Scripting Language
  23 projects | news.ycombinator.com | 25 Apr 2022

  > I would like to see a framework for creating rich REPLs that would be language agnostic, so that I could get a state of the art auto-completion dialog no matter which language I decided to make into a shell.

  It's doable with existing tools. You have LSP to provide the syntactical framework and there's no shortage of alternatives to readline (I'd written my own[1] to use in murex[2], and open sourced that).

  [1] https://github.com/lmorg/readline

  [2] https://murex.rocks

  The problem you still face is that a good shell will offer autocompletion suggestions for strings that aren't language keywords or function names. eg

  - file names; and there's a lot of hidden logic in how to do this. Do you build in fzf-like support, just include fzf wholesale but increase your dependency tree, or go for basic path completion. Do you check metadata (eg hidden files and system files on Windows), include dot-prefixed files on Linux / UNIX, etc. How do you know when to return paths, or paths and files, or even know not to return disk items at all? (see next point)

  - flags for existing CLI tools (assuming you want compatibility with existing tools). Fish and murex will parse man pages to populate suggestions, others rely entirely on the community to write autocompletion scripts.

  - Are you including variables in your completion of strings. And if so are you reading the variables to spot if it's a path and then following that path. eg `cd $HOME/[tab]` should then return items inside a your home directory even though you've not actually specified your home directory as a string. That means the shell needs to expand the variables to see if it's a valid path. But that's a shell decision rather than a language feature.

  Some of these lists might take a while to populate so you then have another problem. Do you delay the autocompletion list (bad UX because it slows the user down) or provide the autocompletion sooner. And if the latter, how do you do that without:

  1. changing the items under what you're about to select causing you to accidentally select the wrong option

  2. communicate that there are update clearly

  3. ensure the UI is consistent when slower loading entries might not fit the same dimensions as the space allocated for the list (if you dynamically size your completions to fit the screen real estate)

  4. ensure that there's still something present while you're lazy loading the rest of the suggestions; and that those early entries on the completion list are worthwhile and accurate

  5. what about sorting the list? Alphabetical? By feature? etc

  The REPL in murex was inspired by IDEs so I've spent a lot of time trying to consider how to provide the best UX around autocompletion. One thing I've learnt is that it's a lot harder to get right than it seems on the surface.

  23 projects | news.ycombinator.com | 25 Apr 2022

  Shameless plug, but the problems you've described are exactly the problems I was looking to solve with my own shell (https://murex.rocks / https://github.com/lmorg/murex)

  > 100% reliable argument passing. That is, when I run `system("git", "clone", $url);` in Perl, I know with exact precision what arguments Git is going to get, and that no matter what weirdness $url contains, it'll be passed down as a single argument. Heck, make that mandatory.

  Variables are parsed as tokens so they're passed to the parameters whole, regardless of whether they contain white space or not. So you can still use the Bash terseness of parameters (eg `git clone $url`) but $url works in the same way as `system("git", "clone", $url);` in Perl.

  > 100% reliable file iteration. I want to do a "for each file in this directory" in a manner that doesn't ever run into trouble with spaces, newlines or unusual characters.

  Murex is inspired by Perl in that $ is a scalar and @ is an array. So if you use `f +f` builtin (to return a list of files), it returns as a JSON array. From there you can use @ to expand that array with each value being a new parameter, eg

    rm -v @{ f +f } # delete all files

  23 projects | news.ycombinator.com | 25 Apr 2022

  The REPL is the shell. The only part we disagree on is whether the language matters and I think it does -- a lot more than you suggest.

  Also you can render images in quite a few terminal emulators already. My shell includes hooks to autodetect which terminal emulator you're using and finds the best method for rendering those images: https://github.com/lmorg/murex/blob/master/config/defaults/p...

• Scripting with Go
  6 projects | news.ycombinator.com | 11 Mar 2022

  https://github.com/lmorg/murex

  (Don't be afraid to self promote!)

  One obvious benefit over what's suggested in the article is that you can use it interactively first, with autocomplete and such goodies, and transition smoothly to a script later.

  6 projects | news.ycombinator.com | 11 Mar 2022
• TermKit: A Rich Graphical Terminal (2011)
  3 projects | news.ycombinator.com | 2 Mar 2022

  To those who are wishing something would fill this void, I'm working on something that does overlap with this. I've already matured the shell somewhat over the last ~8 years. That shell can inline images, manage and manipulate different document formats and convert between them, understanding data types and structures like Powershell but works natively with POSIX CLI tools (which Powershell cannot).

  Last year I also started playing around with WASM and building a terminal emulator in it. The idea being if I can manage the terminal emulator then I can add more features / friendlier UI/UX that might compliment non-CLI users who have been tasked with using the terminal; while power users still have access to the features of the $SHELL in their preferred terminal emulator. There is definitely overlap between what I'm doing and TermKit.

  The idea of doing it this way means I'm still leveraging the foundations already in common use. Opinions about whether they're ready to be deprecated aside, it's the standard everyone already uses so trying to displace that would be an even big hurdle than even just trying to displace Bash. But at least if the standards are reused and extended it does mean people can pick and chose the items that work for them rather than forcing them into an "all or nothing" type scenario.

  I'm not far down the terminal emulator route yet and it's definitely a task that is bigger than the time I personally have to commit to it. So I welcome any time and/or support anyone is willing to donate.

  I should write a blog post about this at some point too....

  The shell (in it's current form): https://github.com/lmorg/murex (docs on Github too but also accessible via https://murex.rocks )

• A note from our sponsor - SonarLint
  www.sonarlint.org | 28 Jan 2023

  Up your coding game and discover issues early. SonarLint is a free plugin that helps you find & fix bugs and security issues from the moment you start writing code. Install from your favorite IDE marketplace today. Learn more →