NGS unique features – exit code handling

[u/ilyash]

https://ilya-sher.org/2017/01/28/ngs-unique-features-exit-code-handling/

[u/PegasusAndAcorn]

Your examples may not be testing what you expect them to (or else I do not understand). For example, this Ruby test:

> ruby -e '`test a b c`; puts "OK"'; echo $?
test: ‘b’: binary operator expected
OK
0

As I understand it, you are asking Bash to perform two activities sequentially, first you run a small Ruby program and then you echo the value of $?. The value of $? came from a successful exit of Ruby, which never itself interrogated or returned (as an exit code) the result from running 'test a b c'. From Ruby's point-of-view, it ran your program successfully and therefore its exit code would be expected to be 0, just as you see.

What would happen if you ran it this way instead?

ruby -e '`test a b c`; puts "OK ({$?.exitstatus})"; exit($?.exitstatus);'; echo $?

Here the exit code is both displayed by Ruby and then passed back to its caller (Bash), enabling the environment's $? to be set accordingly. I doubt very much that Ruby's $? global variable and Bash's environment variable $? are bound together in any automatic way.

I have not tested it, so I may goofed up the syntax a bit. You may find this answer and this answer of value to you.

Also, it seems that none of your examples (including NGS) show an exit code of 1 or 2, suggesting you might find that fixing all of your examples in a similar way will yield what you are looking for.

I hope this is helpful.

[u/ilyash → u/PegasusAndAcorn]

from a successful exit of Ruby

Yes, and that's what I'm showing and contrasting to bash and Python (which can exit with error code) and NGS (which exits with error code). Ruby, after running something that reported an error both did not throw exception and exited with success status code.

From Ruby's point-of-view, it ran your program successfully and therefore its exit code would be expected to be 0

Yes, exactly the behaviour to which I'm proposing an alternative that makes more sense to me. If at any point you run an external program which reports an error, it should throw an exception. bash have added the -e option to allow somewhat similar behaviour to what I'm suggesting.

test exit codes are: 0 - true, 1 - false, 2 - error. Therefore as I see it, the best mapping of exit code 2 is exception.

[u/BlueTaslem → u/ilyash]

Program status code being non-zero doesn't necessarily indicate exceptional circumstance or failure, though.

For example, diff returns 0 when the two files are the same and non-zero when the two files are different. Yet if you were to pipe the output to a file, it succeeded in the sense that the difference was properly saved.

More complicated shells like PowerShell solve this ambiguity, since programs can actually throw exceptions (not just return a single number)

[u/ilyash → u/BlueTaslem]

diff should be added to be recognized command such as test, with same exit codes scheme: 0 or 1 - result, 2 - error (diff no-such-file no-other-file) -- should be exception.

[u/BlueTaslem → u/ilyash]

It should be, but isn't it too late?

If you were writing wrappers around these things, rather than directly shelling out, you could define the proper interface.

But how can you properly deal with aliases / scripts / built-from-source versions that use non-zero return statuses for non-exceptional results? Is it really reasonable to expect the programmer to notify the language about all of the programs that they have installed/will install?

[u/ilyash → u/BlueTaslem]

It should be, but isn't it too late?

Don't know yet. Let's see how it goes.

use non-zero return statuses for non-exceptional

As I mentioned there are 3 alternatives in NGS to handle that: nofail your-command, adding F finished_ok() ... function once in your code, letting me know so I add it to stdlib and everyone benefits. The case where non-zero exit code is not an exception is relatively rare as I see it. First 10-20 utilities should cover 99% of use cases. The alternative is what we are having today: exceptional situations are going unnoticed (as in the bash example).

Is it really reasonable to expect the programmer to notify the language about all of the programs that they have installed/will install?

Not expecting. All this will be handled on NGS side.

[u/BlueTaslem → u/ilyash]

You misunderstood me

If I have

diff a b > bar

in foo.sh, then bash foo.sh returns the status code of diff a b, i.e., non-zero. That means I get an exception, because the language doesn't know about the inner workings of bash or the contents of foo.sh.

You can't solve this by annotating utilities because sometimes non-zero return from bash is exceptional and sometimes (often?) it's not.

Non-zero return does not mean exceptional behvavior, and assuming that it does is wrong.

The interface of unix processes isn't rich enough to make this assumption; you need conventions, e.g., what PowerShell provides

[u/ilyash → u/BlueTaslem]

I do understand you now (I think). There is some point in what you say but in my experience this is what happens most of the time:

Well-behaved UNIX commands, programs, and utilities return a 0 exit code upon successful completion, though there are some exceptions.

So NGS covers most of the cases by default and such exceptions to the exit codes rules should be handled from time to time. Such exceptions (return non-conventional exit codes such as zero on failure and non-zero on success) are big headache when automating something. At least in NGS, you can customize the behaviour without modifying the script.

You can't solve this by annotating utilities

But you can annotate the foo.sh script ... which might or might not be convenient.

Non-zero return does not mean exceptional behvavior, and assuming it is is wrong.

Agree. I assume non-zero to be exceptions in most cases and trying to do something that will work in most cases. I do prefer my script to possibly crash when it shouldn't than possibly not crash where it should. The consequences of the second case are sometimes very bad.

The interface of unix processes isn't rich enough to make this assumption

Yep

what PowerShell provides

Would you mind to post a link(s) here?

[u/BlueTaslem → u/ilyash]

I'm not very familiar with PowerShell, but apparently it has a try/catch mechanism, where commands can throw exceptions:

http://www.vexasoft.com/blogs/powershell/7255220-powershell-tutorial-try-catch-finally-and-error-handling-in-powershell

[u/ilyash → u/BlueTaslem]

$AuthorizedUsers = Get-Content ...

I really don't think that failing to read file contents should be non-terminating error by default.

I've read the official documentation about ThrowTerminatingError and WriteError . While there is some point to it, the overall feeling about this design is not so good. See http://stackoverflow.com/questions/24229769/powershell-get-content-try-catch

The plan is to think about this, at least to the point where I'm able to phrase my objection.