Closed pkoppstein closed 9 months ago
The difference is that jq reads 0
from 000
but gojq reads three 0
s (since 000
is not a valid JSON). So if you run the program with jq, there should be 18 zeros consecutively, which is very very rare.
$ printf '111\n000\n000\n000\n000\n000\n000\n111\n' | jq -cnr -f nonrandom.jq
{"i":7,"last":0,"count":5}
On the other hand, if there are six zeros, gojq emits the output. Which happens sometimes reading from random stream.
$ printf '111\n000\n000\n111' | gojq -cnr -f nonrandom.jq
{"count":5,"i":7,"last":0}
The count might look always 5 but it is an issue of probability. If you run for a long time or limit the digits to 0-5
for example, you'll also see 6 or 7.
@itchyny - Of course! Thanks.
I have a couple of jq programs that read from /dev/urandom or /dev/random without problems, but something weird happens when running the same programs with gojq.
I believe the underlying problem can be demonstrated with the following simple program, which issues a line when a number in a stream of numbers appears more than 4 times in a row:
This command illustrates the problem:
< /dev/urandom tr -cd '0-9' | fold -w 3 | $JQ -cnr -f nonrandom.jq
When run with JQ=jq for a while, the program emits nothing, as expected, but when run with JQ=gojq, it shows that gojq sometimes encounters improbable runs of consecutive 0s:
One point to note is that the run length seems always to be 5. Another is that the problem only arises with 0.
One clue is that the problem goes away if a call to 'jq .' is inserted immediately before the call to $JQ. This suggests to me that there is some kind of race condition involved.