> Is there anything preventing you to have exactly the same functionality but with syntactic sugar that it looks like parameters declaration? (Just to be clear, keeping all the ARGV machinery).

> Something like (assuming local variables are supported; if not, it could still be $args[Flags] etc):

> example code

oooh I like that idea. Thank you for the suggestion.

> Yes it is almost the same in NGS with regards to exit codes, which you preferred not to do in Murex. On the other hand, checking stderr looks very similar to knowing about exit codes and here you decided to go for it. I'm puzzled why. It is somewhat fragile, like knowing about exit codes.

No, murex still checks for exit codes. Essentially a program is considered successful unless the following conditions are met:

  + exit code is > 0
  + STDERR in ('false', 'no', 'off', 'fail', 'failed')
  + or []byte(STDERR) > []byte(STDOUT)

The exit code is self explanatory

STDERR messages are useful for functions that return a message rather than exit code. Particularly inside `if` blocks, eg

  = 1 == 2 -> set math
  if { $math } then { out: $math } else { err: $math }

will return `false` to STDERR because $math == "false" (ie `= 1 == 2` will return "false")

As for the STDERR > STDOUT test, that covers an edge case where utilities don't return non-zero exit codes but do spam STDERR when there are problems. It's an uncommon edge case but the only time this condition is checked is when a command is evaluated in a way where you wouldn't normally want the STDOUT nor STDERR to be written to the terminal.

This also allows you to get clever and do stuff like

  if { which: foobar } else { err: "foobar is not installed }

where `if` is evaluating the result of `which` and you don't need to do more complex tests like you would in Bash to test the output of `which`.