Fix for #2374

[eddyashton]

See #2374 for explanation of the issue.

I've poked around the code and found this possible fix. It's not very neat (checking state->current_input and modifying state->current_line outside of jq_util_input_read_more), but it works and doesn't break any other tests. Please feel free to propose a neater fix if you can see one.

I've also added a regression test. This uses a bunch of functions, so perhaps shouldn't be in shtest? But I don't see input_line_number tested anywhere else.

[owenthereal]

LGTM

[nicowilliams]

This needs to be a command-line option. As @pkoppstein explained in #2374, this would be an incompatible change.

[nicowilliams]

You can probably use input_filename in a reduction (reduce or foreach) over inputs to detect when jq has moved from reading from one file to the next.

[eddyashton]

As @pkoppstein explained in #2374, this change breaks backwards compatibility. Closing for now, will revisit as an additional commandline if I get time.

[emanuele6]

I don't think it matters that fixing this bug "breaks backward compatibility".
The current behaviour is not good, and lets input_filename/0 and input_line_number/0 return values that are wrong.

I think this fix should be merged.

The fix looks good, but there a merge conflict in shtest.

[emanuele6]

Actually, this patch does not fix the issue fully correctly.

If you use --slurp --raw-input, it will stop slurping after the end of the first non-empty file that does not have a final newline, and start reading the rest of the inputs line by line (though still not merging content of different files into one string):

$ printf foo\\n > foo; printf bar > bar; printf baz1\\nbaz2\\n > baz; printf xyz > xyz; printf hello > hello
$ jq -sR . foo bar baz xyz hello
"foo\nbar"
"baz1"
"baz2"
"xyz"
"hello"

[emanuele6]

And this problem also occurs for files in non-raw mode:

$ jq . <(printf 4) <(echo 5)
45

[nicowilliams]

Let's fix this in a separate PR.