Show HN: A smarter Unix shell and scripting environment

That's not the same thing. On macOS it is a Mach-O executable:

  » file ${which open}
  /usr/bin/open: Mach-O universal binary with 2 architectures: [x86_64:Mach-O 64-bit executable x86_64] [arm64e:Mach-O 64-bit executable arm64e]
  /usr/bin/open (for architecture x86_64):        Mach-O 64-bit executable x86_64
  /usr/bin/open (for architecture arm64e):        Mach-O 64-bit executable arm64e

Whereas on Linux it is a shell alias. Doesn't appear to be universal either (doesn't exist on Arch, for example). It was a recent change too, added to Debian 11 (released 2021), which is years after it was added to Murex.

As an aside, I wouldn't be at all surprised if the `open` alias was added to Debian to copy (and I mean this affectionately) macOS. Otherwise `xdg-open` might have just been called `open` from the beginning.

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

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

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.

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

> Did not realize that POSIX after it was obsolete standardized commands ;) anyway.

POSIX does standardise some commands[0], albeit not many and good few of them are implemented as builtins even in Bash. But it also defines STDOUT (etc) files. The way Powershell passes data is as .NET objects. The way Murex passes data is as POSIX byte streams but with type annotations passed out of band. This creates some extra overhead in serialising data but the advantage is that it works with all of your existing tooling without modification.

> Do you write articles about how you make coreutils output structured? Is that a command specific adapter or how does that work?

I haven't but that's a good idea.

The way it works is just that you add type annotations. The default type is assumed text data, potentially in columns, like you'd see from `ps aux` or `ls -l`. There are also some builtins (eg [1][2]) that are data type aware.

So if you just use the most basic features of Murex, you get a few footguns removed (eg by default variables containing spaces don't get split into multiple parameters) and a slightly different syntax to Bash but all the same CLI tools work. However if you want to invest more into Murex then you get greater power from it eg the ability to inline SQL queries[3], write unit tests[4], better error handling[5][6], etc as well as being able to do `jq` like expressions against a multitude of object and table formats.

I really do need to get better at publishing it's features though!

[0] https://en.wikipedia.org/wiki/File:POSIX_Utilities.pdf

[1] https://murex.rocks/docs/commands/index.html & https://github.com/lmorg/murex/blob/master/examples/table-in...

[2] https://murex.rocks/docs/commands/foreach.html

[3] https://github.com/lmorg/murex/blob/master/examples/inline-s...

[4] https://github.com/lmorg/murex/blob/master/config/defaults/p...

[5] https://murex.rocks/docs/commands/runmode.html

[6] https://github.com/lmorg/murex/blob/master/examples/try-catc...

It's a completely new scripting language. It uses C-style braces rather than the more ALGOL-style `if / fi` keywords. However the core syntax of the language should still be familiar to those who use Bash (eg pipes, commands, `$` sigils).

So there is a little more to re-learn than you would with Fish but it shouldn't feel alien to read and write.

My own, personal, use-case is to completely nuke `bash-complet*` off my machine.

To me, bash-completion is horrible. I am looking for a tarball to unwind, and I only remember that it it started with "foo-" and it sure did not end in ".tar" (trying to save keystrokes, y'know). Trying C-i does not pull up anything. Argghh. I am on a machine with bash-completion!

---

I often hit C-a then "a" to get an invalid command (still saved to my hist), or C-a C-k if I think there is nothing else going into the kill-ring. bash-completion absolutely messes with me.

If it works for You, that is great. I really dislike it.

Huh, I had no idea. Just `kill <tab>` then? Will give it a shot next time I'm ak.

Not the person you responded to, but I probably kill an octave or matlab terminal daily. Oops, it turns out this matrix is too big to solve directly. Oops, norm2 takes forever and norm1 would have been good enough.

I suspect they're talking about fzf in general, using `kill` as an example, rather than saying they `kill` stuff often. But I could have misinterpreted their comment.

I didn't mean to imply that I use it "so often," just that it makes it much easier when I do.

I have to `kill -9` neovim once or twice per week due to <https://neovim.discourse.group/t/how-to-debug-intermittent-n...>, that's probably the most frequent culprit.

I really need to compile a debug version and help get that sorted.

Can't have it all I'm afraid. For this reason I keep my zshrc contained to one file so I can easily move it around, but it does require zsh to be available in the first place of course.

All things considered, I'd rather optimize for the 99% of the time I'm on my local machine than the 1% I'm on a remote machine.