pkoppstein

@mcandre - Many people would agree with you, not only regarding the "unexpected" behavior of `contains` but also `index`. It is worth noting, however, that viewing strings as arrays of...

Combining the objects into an array can be done in a single step, i.e. without the -s option $ jq -n '[inputs | {"object": . , "filename": input_filename, "lineNumber": input_line_number}]'...

@wtlangford - I cannot say whether this PR fixes all TZ-related bugs in jq, but I hope that you will keep in mind that the serious TZ-related bugs in jq...

@lilyball - For the record, the online manual for v1.6 (https://stedolan.github.io/jq/manual/v1.6/) mentions --rawfile.

There are many examples of jq (and for that matter gojq) being more permissive in accepting numbers than strictly required by the JSON spec. Many would agree that this is...

@wader, @itchyny - It will probably be a long while before the official documentation is updated, so I was thinking of adding a section to the jq FAQ. How about...

@wader - It seems to me that the behavior of //= that you describe is incorrect and should be fixed, and that it should not be documented except as a...

This ER is essentially a duplicate of #677

@nicowilliams wrote: > ... The builtin would have to raise an error. It could fall back on a simplistic generator, even a jq-coded one (see #677).

@nicowilliams wrote: > OTOH, jq maybe doesn't need bignum operations, just a bignum representation .... bignum operations for the medium or long term; bignum representation for the short term (or...