Jq: Feature request: command line exit status depends on bool

[hhm0]

First of all, thanks for working on this great utility!

Secondly, it would be awesome to have a command line option or the like to have the command-line exit status of jq match the truthiness of the output, zero on true, nonzero on false..

For example: for {"a": true, "b": false, "c": {}}, .a would have an exit code of zero, .b nonzero, and .c would be whatever the javascript truthiness of {} is.

The only question is how to evaluate truthiness, whether it be with ==, ===, or different semantics. I am not an expert in this area, my main reason for using this would currently be for false and true.

[stedolan]

Cool, this sounds useful. There's already a notion of truthiness in jq, so we'll use that.

I think exiting nonzero by default when the output happens to be "false" might be confusing - nonzero often means that the command failed. An "exit" builtin might be better (so exit(.a) would produce no output and return an exit code depending on truthiness of .a).

[hhm0]

I suppose it depends how jq should be used.

If it should be used like a programming language then exit() sounds awesome;
if it should be used like a classic unix sed-type utility, then I
suppose some kind of command line option would be better (for example
--exit to enable exit code modification depending on whether the
resultant value/s are true or false.

I agree that it makes sense to have the exitcode remain 0 unless
specifically changed by the user (for example using one of the above 2
methods).

On 9/13/13, Stephen Dolan [email protected] wrote:

Cool, this sounds useful. There's already a notion of truthiness in jq, so
we'll use that.

I think exiting nonzero by default when the output happens to be "false"
might be confusing - nonzero often means that the command failed. An "exit"
builtin might be better (so exit(.a) would produce no output and return an
exit code depending on truthiness of .a).

---

Reply to this email directly or view it on GitHub:
https://github.com/stedolan/jq/issues/170#issuecomment-24404524

[hhm0]

I realized that it may be good to have this "booleanness" exit code have its own number, so it can be disambiguated from parse errors and the like (see issue #111; exit code 1 is in use there).

[nicowilliams]

@hhm0 hmm, yeah, we should have different exit codes and document them, no?

[hhm0]

@nicowilliams pretty much. Exit code 1 is often used for general
errors (GNU grep is an exception; uses 1 for "not found", 2 for
error), so i'd like to use something higher.

On 12/11/13, Nico Williams [email protected] wrote:

@hhm0 hmm, yeah, we should have different exit codes and document them, no?

---

Reply to this email directly or view it on GitHub:
https://github.com/stedolan/jq/issues/170#issuecomment-30340200

[nicowilliams]

I've fixed it. With the -e option now exit status 0 is for non-false/null last results, 1 is for false/null last result, and, 2 is for usage and system errors, 3 is for jq compile errors, 4 is for invalid results (run-time errors). Without -e jq exits with 0 every time if the program compiles.

[nicowilliams]

@hhm0 I'll close this for now. If you want the exit codes to be different just re-open and comment.

[davidpelaez]

How is this to be used? From the manual I assume jq -e <filter>.

However with the last version downloaded from the website I get this error: jq: Unknown option -e

Full example of the command I'm running:

curl -s 10.0.77.10:8500/v1/catalog/nodes | jq -e ". | length >= 30"

The curl url gives a valid JSON and without the option, jq renders false to stdout. I would like this falsy answer to be reflected in the exit code for simpler use in a bash script. It's most likely a tiny detail I'm not seeing and not a real bug.

Just for clarification purposes, I have jq version 1.3

[davidpelaez]

Ok, so this seems to be a problem of the version? from the releases page, 1.3 is dated May 19 2013, but this issue mentions the addition of the -e flag on December 2013. I compiled this in Fedora from source and the flag works as expected.

[ghost]

We should really add to the documentation the version in which features
appeared.