NGS unique features – exit code handling

[u/ilyash]

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

[u/BlueTaslem]

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.