> 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`.
As in not throwing exception or as in evaluates to true?
> exit code is > 0
You refused to get into specific exit codes for specific programs citing potentially surprising behavior (which I agree will sometimes be an issue).
> STDERR in ('false', 'no', 'off', 'fail', 'failed')
I correlated this with the following source code:
> if len(s) == 0 || s == "null" || s == "0" || s == "false" || s == "no" || s == "off" || s == "fail" || s == "failed" || s == "disabled" { return false
... which also has a potential for surprising behavior. (side note: appears to work on stdout, not stderr)
> or []byte(STDERR) > []byte(STDOUT)
Does that mean len(stderr) > len(stdout) ?
... also has a potential for surprising behavior. I can easily imagine a program with lots of debug/warnings/log on stderr and truthy/non-error output.
> STDERR messages are useful for functions that return a message rather than exit code.
Might be problematic because typically exit codes are used for that.
> 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`.
Mmm.. Never did this. In which situation looking just at exit code of `which` is not good enough?
> if { which: foobar } else { err: "foobar is not installed }
Just to show off :) in NGS that would be:
if not(Program('foobar')) {
error("foobar is not installed")
}
> 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:
The exit code is self explanatorySTDERR messages are useful for functions that return a message rather than exit code. Particularly inside `if` blocks, eg
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
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`.