> I'm highly interested about the error handling and testing baked into it.

The big two things with error handling is try[0] and trypipe[1] which work much like `-e` and `-o pipefail` (respectively) in bash. The difference is the syntax is structured more like Java's `try` and `catch` blocks so you can gracefully handle errors without having to check the exit code of each command.

The big divergence from your traditional shell is that STDERR is monitored and if the number of bytes written to STDERR is greater than STDOUT then the process will be treated as if it had a non-zero exit code (while not altering the actual exit code just in case `0` is meaningful for that process).

Conditional blocks like `if`, `switch` etc also treat the exit code and STDOUT/STDERR output as part of the boolean conditional, eg

    !if { which foobar } then {
        out "foobar could not be found"
    }

As for testing, I badly need to add more detail to the `test` docs[2] because they explain the syntax but not how nor why you might want to use it.

Essentially there are a few different tests:

- inlined test: this is where you write tests inside your function and attach them to a process via a special "test" pipe. When that function is executed the tests are either ignored (normally), or logged (when test mode is enabled). If the test mode is enabled then the tests attached to the process check that the process is in the expected state (eg the right type of content written to STDOUT et al, exit code, etc). This is a good way of monitoring processes in scripts and helps massively with debugging.

- state: this really should have been called "watch" since that's the crux of what it is, albeit it's not a simple variable watch, you can write shell scripts as part of the state checks so you can have greater flexibility into the runtime inspection. This is also attached to processes via a special pipe.

- unit tests: this is much closer to the kind of testing one typically thinks about as developer. Unit tests, when run, will also output the inlined and state results too and the reporting format can be changed too.

There is also a debug mode which is more verbose. It prints, unsurprisingly, debug messages I've written into the shell. But it also prints error messages that might normally be suppressed (eg in the `if` example above, you wouldn't normally want `which` to print it's error message since you only care about whether it passed or failed. But with debug turned on those error messages would also be printed).

A few other features that help with day to day operation with regards to errors:

- STDERR is printed in red text (this can be optionally turned off if it's not to your tastes)

- Builtins print not just the application raising an error but also the line numbers. This is particularly handy given the functional nature of shells (ie every structure, such as `if` etc, is a builtin command).

- Every script that's loaded, function/test/autocomplete/etc stored also logs where it was loaded from and when (all visible in the `runtime` command) so you can clearly inspect every bit of running code in murex and where it was loaded from).

[0] https://murex.rocks/docs/commands/try.html

[1] https://murex.rocks/docs/commands/trypipe.html

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

> Moving away from the most common shell syntax is a bold move, but not necessarily a bad one, shell scripting needs some fresh air :)

Yeah. That happened more by chance than design. Happy to discuss more about this if you wish but man this post is already lengthy hehe