readline
murex
readline | murex | |
---|---|---|
2 | 55 | |
23 | 1,370 | |
- | - | |
10.0 | 9.6 | |
about 3 years ago | 8 days ago | |
Go | Go | |
Apache License 2.0 | GNU General Public License v3.0 only |
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.
readline
-
Charm: a new language in, with, and for Go
... I kind of am, though. Which is why I didn't know what to do. I don't see a lot of free open source projects with extensive documentation in their README. Some, yes, but for example here's the readline library I'm using. I, in my well-meaning ignorance, supplied 50 pages of documentation and people are behaving like I ate a baby 'cos it's in the wrong format. I will now put it all in the README as people would like, but I did genuinely act out of ignorance and not out of a wish to insult the customs of the tribe.
-
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
[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.
murex
-
Show HN: a Rust Based CLI tool 'imgcatr' for displaying images
This is how murex works too https://github.com/lmorg/murex/blob/master/config/defaults/p...
- Xonsh: Python-powered, cross-platform, Unix-gazing shell
-
The Bun Shell
I agree. I’ve written about this before but this is what murex (1) does. It reimplements some of coreutils where there are benefits in doing so (eg sed, grep etc -like parsing of lists that are in formats other than flat lines of text. Such as JSON arrays)
Mutex does this by having these utilities named slightly different to their POSIX counterparts. So you can use all of the existing CLI tools completely but additionally have a bunch of new stuff too.
Far too many alt shells these days try to replace coreutils and that just creates friction in my opinion.
1. https://murex.rocks
-
Jaq – A jq clone focused on correctness, speed, and simplicity
This is exactly what Murex shell does. It has lots of builtin tools for querying structured data (of varying formats) but also supports POSIX pipes for using existing tools like `jq` et al seamlessly too.
https://murex.rocks
- Murex rocks v5 is out
-
The Case for Nushell
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.
- Murex
- FLaNK Stack Weekly for 20 June 2023
- Show HN: A smarter Unix shell and scripting environment
-
Nushell.sh ls – where size > 10mb – –sort-by modified
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.
What are some alternatives?
Lisp-in-Charm
elvish - Powerful scripting language & Versatile interactive shell
stshell
nushell - A new type of shell
hush - Hush is a unix shell based on the Lua programming language
tidy-viewer - 📺(tv) Tidy Viewer is a cross-platform CLI csv pretty printer that uses column styling to maximize viewer enjoyment.
u-boot - "Das U-Boot" Source Tree
fx - Terminal JSON viewer & processor
shelljs - :shell: Portable Unix shell commands for Node.js
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.
go-regex - A High Performance PCRE Regex Package That Uses A Cache.
xonsh - :shell: Python-powered, cross-platform, Unix-gazing shell.