New Feature: `onyo get` return codes should match `grep`'s

[aqw]

Currently, onyo get returns 1 only if there is an error.

I propose that we match grep's behavior, which allows for some useful functionality.

From grep's manpage:

EXIT STATUS Normally the exit status is 0 if a line is selected, 1 if no lines were selected, and 2 if an error occurred. However, if the -q or --quiet or --silent is used and a line is selected, the exit status is 0 even if an error occurred. ... -q, --quiet, --silent Quiet; do not write anything to standard output. Exit immediately with zero status if any match is found, even if an error was detected.

I propose that onyo get:

• return 0 if matches were found
• return 1 if no matches found (i.e. no results)
• return 2 for error

We already have --quiet as part of onyo --quiet

I cannot think of an error in onyo get that still leads to a successful query. So we can ignore that aspect of their functionality.

The real value of --quiet is to abort searching early once a match is found. But that optimization (and its architectural tradeoffs) is not within the scope of this issue. If desired, a separate issue should be opened to track that.

In the end, this functionality would allow for scripts such as the following:

for d in $(onyo get --type directory); do
    onyo --quiet get --type directory,asset --include "$d" || echo "empty dir: $d"
done

[nhjjr]

This is an informative distinction and programmatically reliable, since return 1 in your suggestion is easier than catching 0 in stderr and No assets matching the filter(s) were found in stdout.

[bpoldrack]

+1 in principle

I cannot think of an error in onyo get that still leads to a successful query.

That may be the case WRT to validation. In get we might easily stumble upon a file, that's not an asset but also not onyo-ignored yet (there's an error message for it, but it has no effect on the exit code as of now - regardless of switches). Similar things could happen with any sort of validation failure or invalid asset files.

[aqw]

Hmm... I see your point. Maybe this behavior will change as we approach fsck, but our general idea has been to abort fully if the repo or asset is invalid in any way.

I think for now I would like to continue with that assumption, until we load the headspace of fsck and "what guarantees are we making by even invoking onyo".

If +1 in principal... I have opened #683 :-D