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 →
Murex Alternatives
Similar projects and alternatives to murex
-
tv
📺(tv) Tidy Viewer is a cross-platform CLI csv pretty printer that uses column styling to maximize viewer enjoyment.
-
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!
-
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.
-
-
-
-
zsh-history-substring-search
🐠 ZSH port of Fish history search (up arrow)
-
-
SonarLint
Clean code begins in your IDE with SonarLint. 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.
-
jc
CLI tool and python library that converts the output of popular command-line tools, file-types, and common strings to JSON, YAML, or Dictionaries. This allows piping of output to tools like jq and simplifying automation scripts.
-
-
-
terminal
The new Windows Terminal and the original Windows console host, all in the same place!
-
-
-
-
-
-
docker-flask-example
A production ready example Flask app that's using Docker and Docker Compose.
-
bash-timestamping-sqlite
bash commandline timestamping using a sqlite database for personal analytics, activity logging and auditing
-
SaaSHub
SaaSHub - Software Alternatives and Reviews. SaaSHub helps you find the best software and product alternatives
murex reviews and mentions
-
VanadiumOS: Portable, multi-user Unix-like OS
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
> 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).
-
Enter a command to see help text for each arg
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)
-
Guide: Hush Shell-Scripting Language
> 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
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.
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
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
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.
-
TermKit: A Rich Graphical Terminal (2011)
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
Stats
lmorg/murex is an open source project licensed under GNU General Public License v3.0 only which is an OSI approved license.