Hacker News Reader

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.

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).

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.

> `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.