PowerShell also runs on Mac, Windows, and Linux. You pass objects instead of plaintext through the pipeline which provides a rich experience. The full .NET type and ecosystem are also available when you really need a full fledged class for a thing.
murex also passes objects. The difference is the objects are passed as UNIX byte streams but with an additional data-type meta field. So processes written in murex can have PowerShell-like objects but at the same time standard POSIX utilities can still be added to the pipeline with no additional effort.
That latter point is, in my opinion, the biggest hurdle to using PowerShell.
Of course, it ultimately boils down to personal preference and for some, .NET support is a killer feature.
The cross-platform pwsh is actually what inspired me to go on the hunt, and was the first thing I tried. But while it’s good on Windows, using it on POSIX just felt… wrong, somehow. I later discovered uutils/coreutils (a Rust reimplementation of GNU coreutils that works on Windows) and decided it’s easier to bring my POSIX workflow to Windows than the other way around.
WSL on Windows replaces the need for uutils/coreutils. Running an actual distribution of Linux on Windows with WSL provides an actual Linux/POSIX environment.
In my experience, there is a graveyard of tools that I tried which attempted to create native POSIX ports for Windows. Each port came up short in my workflow every time. PowerShell and WSL provide me and the teams I work with an experience that simply works.
The magic thing that powershell has is that its objects are full .net objects so you can do method calls etc and not just structured data, so you can do stuff like
Get-Foo | % { $_.bar() }
Which is roughly equivalent to e.g. python
map(lambda x: x.bar(), getFoo())
Does murex have anything like that? Generally serializing objects (with methods) is to byte streams is not trivial nor without tradeoffs
Not directly but you can execute code dynamically. eg
Get-Foo | [ bar ] | source
would be the equivalent murex code.
PowerShell is definitely more sophisticated here because .bar is recognised as a method. Whereas in murex it's just a text field that you're asking the interpreter to execute as code.
murex breaks POSIX compliance massively because it acts as a proxy between each command in the pipeline. This means it can forward type information to processes within murex (eg builtins) but read and write byte streams to external commands.
As mentioned to one of your other replies, this causes a few issues (eg forking). But processes are still run in parallel like with a traditional shell and 99% of time this massive cheat is transparent to both the running processes and the users too.
This cheat does allow for some additional features though, like
- colourisation of STDERR (so it stands out)
- STDERR byte count used to judge if a process has failed
(possibly a few others I've forgotten but have to dash now for a lockdown Zoom party....sorry)
PowerShell maps plaintext to objects without issue. No need to drop down into bytestreams.
In the following example, 'choco' (Chocolatey) outputs a list of outdated packages in a consistent format (--limit-output). The text output is piped to the ConvertFrom-CSV PowerShell CmdLet, which maps the text output from choco into a PowerShell object.
PowerShell is also unnecessarily verbose for me and wasn't even available on non-Windows systems until midway through murex's life.
Plus it's easy to cherry pick specific features between different solutions and argue they're equivalent if you're going to ignore all the other aspects where they differ. For example a big part of murex is the REPL environment:
- murex parses man pages for smarter auto-competions
- murex integrates well with `tmux` for those who want a richer tiled TUI
- murex supports vim keys
- murex give context sensitive hints upon every keystroke
- murex has an events system baked in. So you can assign your own shortcut keys or run scripts upon filesystem changes
- murex supports regex searches through auto-completions. Which makes navigating directories quicker. It makes finding application names in `kill` quicker. etc
I'm not saying any of this to be critical against PowerShell - it's a sophisticated piece of engineering and a great solution for a great many people. But the differences between what I've built and PS are far greater than the properties they share.
There are good choices in 2021.
https://docs.microsoft.com/en-us/powershell/scripting/instal...