I gave it a spin. First it complained about aspell dictionaries, then I tried installing a package in an effort to improve the prompt from simply saying "murex":
murex » murex-package install https://github.com/orefalo/murex-module-starship
\* Getting package from 'https://github.com/orefalo/murex-module-starship'....
Error in `murex-package` (0,1): protocol handler for HTTPS has not yet been written. Please use git in the mean time (you can do this by specifying a git extension in the uri)
.murex_modules » murex-package install https://github.com/orefalo/murex-module-starship.git
\* Getting package from 'https://github.com/orefalo/murex-module-starship.git'....
Cloning into '/home/aroedset/.murex_modules/murex-module-starship'...
Error in `murex-package` (0,1): \* Package 'murex-module-starship': Error loading module `starship` in path `/home/aroedset/.murex_modules/murex-module-starship/starship.mx`:
> \* Missing required executable, builtin or murex function: `starship`
.murex_modules »
And then the time I allocated for myself for trying out a random shell I found on the internet was up.
The first is definitely a known limitation already, so a bug report isn't particularly useful, and the second is not a bug, just a missing dependency. Maybe the error messages could be friendlier, but they're not particularly difficult to parse.
Because I need the scripts and snippets I write for my repos to work for other developers, I'm going to write them to be bash compatible. That applies also to scripts and snippets written by others that I consume.
So if a shell is not bash syntax compatible, then it really has to offer some astonishingly useful features to offset my having to translate and map the scripts I need to run for it.
Murex does not interpret "$(cmd args)". So unfortunately, I cannot use it. I know it's not fair, and I know that is promoting a lock-in of what shells can do, but I need to get shit done I'm afraid.
A thousand times this. I use bash scripting for things I’m going to distribute, but do all my local CLI work and scripting in fish because life’s too short to wear the bash hair shirt when I don’t have to.
For me to develop my scripts it would help alot if my interactive shell supports the syntax as well. I mean you are right of course, I CAN do that, but it then becomes a tradeoff question again of whether this non-compatible interactive shell has sufficient niceties.
I agree with you. Have you tried Fish? I find it to be the perfect balance of these goals. It has lots of niceties, which for me was already enough to switch to it years ago. But lately, they’ve been adding lots of bash compatibility, which has made it even more awesome.
You're not wrong, but I don't think this is either very useful feedback or an interesting comment.
What you're saying applies to all core non established technologies: languages, operating systems, file formats, protocols, plugin ecosystems. If you're in a situation where that's non negotiable then obviously you're not the target audience here.
Murex were the shells whose excretions were used to make the Tyrian purple of the Mediterranean. Tyrian referring to Tyre, one of the major Phoenician city-states.
It was so iconic that the "Punic Wars" are called that because Punic = Phoenicia = "Purple People".
Carthage was the Phoenician colony that outlasted the home country.
Also, the Phoenicians were the descendants of the Canaanites, who (according to one etymological theory) are also named after the color purple.
The Phoenicians were a semitic people like the Jews, and they gave the world its first alphabet which was adopted by both the Hebrews and the Greeks. The Greeks added vowels, and the Romans adopted that alphabet and it became roughly the one we use today.
If you go to the Wiki page (https://en.m.wikipedia.org/wiki/Phoenician_alphabet) and scroll down to the Table of Letters header, you can see how the letters evolved from Egyptian hieroglyphs to the letters we use today. It’s particularly interesting to me that our letter “B” (which the greeks called “beta” and which forms the tail end of “alphabet”) was originally a house, and the semitic languages called it “bēt” which was their word for house, which you can still see today in Biblical place names like Bethel (house of God—“El” was a very old name for God).
It's interesting how, unlike Sumerian cuneiform or Egyptian hieroglyphs that were complex systems that came from dedicated scribes of the court, Phoenicia's alphabet was the kind of pragmatic system you can imagine a more mercantile society developing.
It's wild that it turned into the scripts: Latin, Greek, Arabic, Cyrillic, Hebrew, and beyond.
Also interesting is Chinese script, which was saved from this by Stalin telling Mao that China should keep its unique writing, which Russia of course was already doing. Mao did do the simplification, but he turned away from his previous plan to standardize the latin script for Chinese.
Murex also has significant religious significance to Jews. It is the source of the biblically mandated blue threads for four cornered garments: https://en.wikipedia.org/wiki/Tekhelet
Thanks for pointing it out. I've tried both as interactive shells for a few minutes. Murex seems to have a more minimalist approach that works well as a drop-in replacement.
However, I have trouble understanding some design decision, such as inventing redundant keywords. And I've spotted bugs in boths (e.g. ls --literal fails in nu, and the completion proposes it twice in Murex).
`ls` is not the same command in nu. There's a nu-specific `ls`.
My GNU `ls` has `--literal`, but to do that in nu, you have to do `^ls --literal`, to use the external command instead of the nu builtin.
You can see the nu `ls` options with `help ls`, or `ls --help`. `--literal` is completely useless for nu's `ls` anyway. `nu`'s ls gives a table, where the `name` column is the filenames. There's no need for any quoting, because it's already structured output.
> However, I have trouble understanding some design decision, such as inventing redundant keywords.
Murex author here: The design was originally based around explicitness. Though that's not to say that the design works everywhere. So I'm definitely interested to understand where you think improvements can be made. Please do leave some feedback in Github.
Maybe I’m just not the target audience, but looking at the front page, I don’t see what actual problems this solves. The claims sound nice, but without examples of what they mean in real world use, it’s not really compelling.
I may be wrong, but it gives me some powershell vibe. Since it seems to be targeted for macOS, I would assume it "solves" the lack of powershell equivalent on Mac ?
Powershell 7+ (a long while ago named core) is the version you should use on ALL platforms, including Windows. It's just the most recent version.
"Core" gives off a vibe that it is some limited thingy. It's not, it's full PS.
Murex works on a multitude of platforms, including Linux and Windows. But also a variety of UNIXs too.
It was actually first created before Powershell was available outside of Windows. But some of the design philosophies are fundamentally different to Powershell too. For example Murex is designed to work well with POSIX (bar the shell syntax itself), whereas Powershell reimplements most of the stack, including coreutils.
It takes 3.5 seconds for a new login shell to open on my laptop, which has a decent CPU and a fast SSD. I do have quite a few lines of config, but no oh-my-zsh and almost no plugins. I have around 2k SLOC of ZSH config.
Meanwhile, I have 22.3k SLOC of Emacs Lisp config, and Emacs starts up (granted, after lowering bytecode to native code AOT) in ~4 seconds. To me, that suggests there's something really wrong with ZSH in terms of performance - unfortunately, it's better in almost every other way compared to BASH, so I learned to live with that. Still, at least in my setup, ZSH indeed is slow, even on modern hardware. I wonder if it would even run on a 486...
That sounds way too long. Mine takes like 15 ms on a 2015 cpu and I activate zsh-syntax-highlighting and new style completion and everything, but yeah oh-my-zsh often adds nutso overhead. Anyway, I suggest you profile your zsh start-up. Here's one copy-paste friendly way to do that:
(PS4='+$EPOCHREALTIME ' zsh -licx exit)2>err
era=$(grep '^+[1-9][0-9][0-9][0-9][0-9][0-9][0-9][0-9][0-9][0-9].[0-9]*' <err |
head -c6) # c6 here rounds to 100_000 seconds (eg +17483xxxyy)
awk '/^\'${era}'[0-9][0-9][0-9][0-9][0-9]\.[0-9]*/{
if (c) printf "%.06f %s\n", $1 - t0, c; t0 = $1; c = $0 }
END { printf "%.06f %s\n", 0, c; }' < err | sort -g > startup-profile
(Note for $EPOCHREALTIME to work you need a `zmodload zsh/datetime` somewhere early on. I might suggest at the top of `$ZDOTDIR/.zshenv` for this kind of thing.)
Also, if something seems limited by "just parsing", you can usually speed that up a lot with `zcompile`. I do that with a `.zcompdump.zwc` and a `digraphs.zsh.zwc`.
EDIT: I noticed myself that really large HISTSIZE (in the 100s of thousands, and with such limit realized) combined with de-duplication seems to be a bad combination. I just lowered my HISTSIZE with a when-too-big spool-off for longer term history/cold storage.
...right, I totally forgot that. Yeah, my history file is 4.5MB, and $HISTSIZE is 1M. I even wrote a Scala app[1] some time ago to collect hist files from all my machines (I used many more than the current 2, at some point), merging and deduping them once a day. Adding to that, it's 13 years old at this point, and probably has quite a few KB of mis-pasted text files in it, so I guess it makes sense it's this large. It also makes sense that processing it takes a while, especially with deduping enabled.
I'll check, but if that's the reason, then I'd be reluctant to do anything with it. Having fzf search through all my command lines dating back to 2012 is very valuable. I'll see how that would work with spooling.
Thanks for the profiling tip, I'll check it out! As mentioned, I'm not thinking of jumping ship, so I'm willing to do some digging to make the situation better :)
-▶ time HISTFILE=/dev/null zsh -c 'echo $ERL_AFLAGS' # variable from the end of my .zshrc
-kernel shell_history enabled
HISTFILE=/dev/null zsh -c 'echo $ERL_AFLAGS' 0,20s user 0,03s system 98% cpu 0,233 total
In that case, since you are already de-duping "externally", you might play with `setopt HIST_IGNORE_ALL_DUPS HIST_IGNORE_DUPS HIST_SAVE_NO_DUPS` combinations. It's been many years since I looked at it, but I think these conspire with large saved histories to slow things down a lot at startup/initial history parse.
I don't even recall if it's necessary or was just the simple algorithm. So, you might actually be able to get Zsh fixed if there is some quadratic thing that can be turned linear with a hash table. The Zsh mailing list is quite accommodating in my experience.
Not sure what you find clunky about PowerShell. On the other hand, I find nushell not mature enough to be usable. The very basics - displaying command output in lists and tables - is totally broken as soon as some long strings appear in the output. Various issues about this are logged, but nobody seems to care.
