jqlang/jq

jq 1.6 different (incorrect?) behavior for tonumber? // tostring compared to jq 1.5

evantorrie opened this issue · 9 comments

evantorrie commented

Describe the bug
jq-1.6 behaves differently (and as I read the manual, incorrectly) when running map_values with a filter which includes an alternate //.

To Reproduce

% jq-1.5 'map_values( tonumber? // tostring)' <<< '{"fish": "food", "account": "1234"}'
{
  "fish": "food",
  "account": 1234
}
% jq-1.6 'map_values( tonumber? // tostring)' <<< '{"fish": "food", "account": "1234"}'
{
  "fish": "food"
}

Expected behavior
Expected jq-1.5 output to appear in both cases

Environment (please complete the following information):

  • MacOS Mojave
  • jq version 1.5.3 and 1.6 (poured from homebrew bottles)
nicowilliams commented

Thanks for the report!

nicowilliams commented

Oddly this is fixed in my dlopen branch...

pkoppstein commented

Note that the problem seems to have nothing to do with // and everything to do with ?:

$ jq-1.6 'map_values( tostring?)' <<< '{"fish": null, "account": "1234"}'
{}
nicowilliams commented

@pkoppstein yes, it's probably another manifestation of #1859.

Alanscut commented

hi , @nicowilliams
I tested your branch “dlopen” , but the output is wrong

jq 'map_values( tonumber? // tostring)' <<< '{"fish": "food", "account": "1234"}'

result:
{
  "__jq": 1,
  "__jqv": 1877772117465177
}

This situation is also handled incorrectly, so This bug may not have been fixed perfectly

 echo ['1'] | jq  'map_values(tonumber)'
{
  "__jq": 0,
  "__jqv": 1514811160447560
}
nicowilliams commented

@Alanscut it's fixed in my dlopen branch now, and there are tests for #1859 in it.

Alanscut commented

@nicowilliams Thanks for your work，The result of the current dlopen branch is correct.

nicowilliams commented

@Alanscut thank you for testing it!

benaryorg commented

Any chance of getting a fix for this released as this is breaking behaviour for jq-1.6?