iquest silent when no results about irods_client_icommands

[alanking]

A similar issue was raised and changes were merged for 4.3.0/4.2.12 here: irods/irods#4745

In those changes (found here: 64df8a9), iquest returns a code of 1 when CAT_NO_ROWS_FOUND is returned from the server. Would this be sufficient to meet your use case?

[tedgin]

That solves half of what I was proposing. An empty result set isn't always an error though. Pretend that I want to write a script that searches a set of collections for for a data object with a .jpg file extension. When it finds one of these files, it emails the file to Terrell. The script iterates over the set of collections and uses iquest to find data object with that file extension. It shouldn't be an error if one of the collections doesn't have a file with that extension, so the script would need to trap iquest errors. When it detects an iquest error, it would need to determine if the error is because of an empty result set or some other reason. If iquest could run in the second mode I proposed, the script would need to do this. An error would be a problem with iquest or the query, not an empty result set.

[trel]

My first reaction is that this should be on the calling script to handle/trap the errors/empty results.

We can make sure that all 'actual' errors do not produce a return code of 1 (similar/same as grep).

[mcast]

@tedgin wrote:

Maybe iquest could have two modes.

The first mode would treat an empty result set as an error. iquest would write CAT_NO_ROWS_FOUND: ... to stderr and exit with a failure status.

The second mode would not treat an empty result set as an error. It would write nothing to stderr or stdout and would exit with a success.

For me that makes a lot of sense - I have a wrapper on iquest which interprets the 4.2.7 way, but in other/transient code which doesn't reach that... it has caused bugs when I forgot.

This wrapper will need changing for 4.2.12/4.3.x when we get there, but that's OK.

The first mode could be the default. The mode could be selected by passing a command line option --empty=(failure|success) something like that. If no option is provided the default could be the first mode.

If backwards compatibility was a strong preference, the "legacy" behaviour could be a (third option) default. This isn't particularly useful for me, and I can see the value in using what is already done -

@alanking wrote:

A similar issue was raised and changes were merged for 4.3.0/4.2.12 [...]

@trel wrote:

My first reaction is that this should be on the calling script to handle/trap the errors/empty results.

We can make sure that all 'actual' errors do not produce a return code of 1 (similar/same as grep).

Having a disctinctive exit code is essential for reliability.

After that I see it as a choice in supporting different types of caller,

1. the lazy ones who expect everything will be fine (no errors or unexpectedly empty results) and hopefully the process will stop upon error; they don't worry about complexities such as exit codes
2. the thorough ones who check all the exit codes and raise relevant exceptions in response.

Not written to patronise anyone - I can be in either group depending on the context, and by using shell captures or pipelines one can too easily end up in the first group without realising.

There is a lot to be said for making it work like grep, although GNU Grep has many flags to add flexibility.