Hacker News Reader

Comment by SushiHippie | Hacker News Reader

Reminds me somewhat of nushell[0]. It's mindblowing what's possible with it. It makes the oneliners you normally write more readable, but I'm still using a "normal" shell (zsh) as I can't use these everywhere I want, compared to most of the oneliners that only depend on coreutils and can be run on any gnu/linux system.

If I'd need to install another tool to take my scripts with me, I'll probably would just use another scripting language like Python.

[0] https://www.nushell.sh/

View on HN

Nushell is pretty awesome but the one problem with Nushell is it requires commands to "speak" nushell for it's magic to work. Take the example on the landing page with `ls`. `ls` is actually a nushell builtin rather than GNU / BSD / whatever coreutils: https://www.nushell.sh/commands/docs/ls.html

Whereas Murex colours pipelines with type annotations so that it can perform it's magic with your existing system's coreutils.

That's not to say that Nushell's approach is wrong. It's a popular approach used by a few alt shells, including PowerShell. But it does come with trade offs:

1. your coreutil muscle memory needs to remember whether you're in Nushell or Zsh (eg `ls` flags will differ depending on your shell)

2. the developers of Nushell need to re-implement coreutils to expose the genius of their shell. And as we've seen on here before, developing and maintaining coreutils is far from a trivial task

3. any other CLI tools that people might use that might not be common might also not support Nushells magic

These problems doesn't exist for Murex because it is basically an abstraction on top of POSIX.

To be clear though, I'm not making a criticism about Nushell. Murex has it's own problems and trade offs as well. So please take this comment only as a description of where our approaches have differed (I think it is great that there are numerous options these days).

> `ls` flags will differ depending on your shell

This just sounds like a non-starter for me. I'm already irritated by having to deal with both BSD and AT&T flavors.

But, to each their own.

To be clear, my shell doesn't take this approach. But I do completely agree with you. This was precisely I took a different approach.

I'm not sure I was clear on that so thanks for pointing it out.

It should be noted that `ls` is kinda of a (interactive convenience) special case by itself, if you really need to parse `ls` output, you're in a world of hurt on any conventional raw_byte_stream+pipes based shell [1]. Most (non-interactive) tasks done with ls should instead be done with other, safer shell builtins or more appropriate tools.

[1] https://mywiki.wooledge.org/ParsingLs

I completely agree. Murex also includes a few machine parseable builtins for this reason:

https://murex.rocks/docs/tour.html#filesystem-wildcards-glob...

But I do think being able to work with your systems coreutils is a valuable convenience too.

I think that's a good comment on Nushell. I agree that it's doing lots of things right and is at the very least an excellent proof-of-principle regarding how our shells _should_ behave, but at a very high cost of lost interopability.

> the developers of Nushell need to re-implement coreutils to expose the genius of their shell.

Yes, or if Nushell is going to try not to be interoperable with existing POSIX commands, then the project needs to focus much more on perfecting the design of its exposed library of builtins.

Yeah. This is a little half-baked, so bear with me....

It seems to me like tools like bash, lmorg, nushell, and PowerShell exist in some kind of continuum (which I think is, from left to right as I've indicated them above, the amount of "smarts"/type information objects returned from commands have). Perhaps not coincidentally, the further right you go, the more what you have starts looking like a programming environment than a shell to execute other programs.

As long as the command supports some structured output, such as json, it is very easy to get back the magic.

I have written a bunch of scripts that basically manages my whole home server using podman by leveraging `podman --output=json`. Most new tools support json output that make it easy, and by adding an alias that adds the `--output=json | from json` (or the equivalent for each command) it works pretty much the way you would expect.

For others that don't, you just need to add a little parsing to kick it off. Here are some examples on their github[0]. Once you have what works, just add it as an internal command, and it's a "fixed" problem.

I personally prefer nushell's method, as it allowed me to add tools that do some more advanced stuff pretty quickly.

[0] https://github.com/nushell/nushell/issues/2029

You can do that in Murex too. In fact it's even easier than the examples given because Murex expects STDOUT to be structural data by default. You just need to tell it what the format is if the pipeline isn't type cast by default.

I don't have Windows to test Windows `netcat` on but the Murex code would look something like this:

  netstat -ao -p tcp -b | [Proto..]r | tabulate --separator "  +" | [Proto "Local Address" "Foreign Address" State PID]

  # [Proto..]r -> select every line after the regexp expression "Proto"
  # tabulate --separator "  +" -> by default columns are split on whitespace. But here we are saying use two or more spaces
  # [Proto "Local Address" "Foreign Address" State PID] -> selects columns (we already have column titles from `netstat` so why reinvent the wheel?)

Likewise with your `podman` examples, in murex this would look like:

  function podman {
      cast json
      exec podman --output=json @PARAMS
  }

You can even configure Murex REPL to only autocomplete commands that support JSON input from `podman`:

  method define podman %{ Stdout: json }

...so now when you type `podman | <tab>` you only see commands that are compatible with JSON.

I do have a lot of respect for Nushell but I've been using Murex as my primary shell for longer than Nushell has been around so a lot of these edge cases have been solved in Murex too. I just don't do a particularly great job at advertising it :)

Fair enough. Though the difference between your netstat examples and the podman examples and the nushell examples are minimal at best. Even if I understand the difference of the implementation (between "coloring" the output, and parsing it).

Why zsh over bash? Just curious.

I've used zsh for many years, and for me the biggest wins were the various globbing enhancements that all but removed the need for `find`. I know bash has caught up on a lot of these but now it's just momentum.

I do script with bash, however.

find did itself such a disservice with it's syntax.

    find . -name 'somefile'

should have been just

    find 'somefile'

Ie, defaulting to the current dir and default to find via name.

Yeah I don't like using find's predicate options, I often just do

find | grep somefile

because I can also use all the pattern syntax I use elsewhere in grep commands.

You might like https://github.com/sharkdp/fd. I use it as it is fast, although I've used `find` for so long I have to think about the differences before I do.

I also still script in bash, as zsh sometimes has some minor deviations that are not directly that obvious.

One of the reasons I use zsh is because of all the plugins that exist for it. With them I have the feeling that they boost my productivity. But the real reason is, zsh feels more like it does what I want/expect compared to bash (, that is probably subjective?).

Reply on news.ycombinator.com