jq:错误(在<stdin>:0处):无法遍历null(空)

时间:2019-02-20 20:30:03

标签: jq

我一直在使用API​​调用来将其构造为JSON格式,因此以后可能会将其推送到数据库中。然后代码如下:

getPage() {
curl --fail -X GET 'https://api.app.com/v1/test?page=1&pageSize=1000&sort=desc' \
  -H 'Authorization: Bearer 123abc456pickupsticks789' \
  -H 'cache-control: no-cache'  
}

getPage \
| jq -c '.items | .[] | {landing_id: .landing_id, submitted_at: .submitted_at, answers: .answers, email: .hidden.email}' \
  > testpush.json

尽管运行它,但会产生以下错误:jq: error (at <stdin>:0): Cannot iterate over null (null)

我研究了诸如this oneor this one from this sitethis response.的解决方案

常见的解决方案似乎是在?前面使用[],我在靠近底部的jq行中进行了尝试,但是仍然无法正常工作。它只会产生一个空的json文件。

我是否从其他答案中误解了要点,而不是将我的?放在正确的位置?>

2 个答案:

答案 0 :(得分:0)

为防止.items不是数组的可能性,您可以编写:

.items | .[]?

或:

.items[]?

或更强大:

try .items[]?

但是,这些都不提供针对无效JSON输入的保护。


p.s。以后,请遵循mcve准则(http://stackoverflow.com/help/mcve);在当前情况下,如果您根据curl命令产生的输出提供了一个说明性的JSON代码段,将会有所帮助。

答案 1 :(得分:0)

在解析该数组时,必须让JSON知道它可以在意外值后继续。 try 是完美的选择。

请记住,要么必须保证数据,要么让解释器知道可以继续。听起来可能有些多余,但这就像是一种故障保护方法,可以防止难以跟踪/通知的意外结果。 另外,有必要了解 之间“测试”的区别吗? vs try

假设 $ sample 符合JSON标准,以下代码将始终有效:

sample='{"myvar":1,"var2":"foo"}'
jq '{newVar: ((.op[]? | .item) // 0)}' <<< $sample

因此,对于 $ sample 来说, op 数组为 null ,但是很明显jq它可以继续运行而无需询问您的干预/修复。


但是,如果您确实将假定为与 try 相同,则可能会出错(请我帮忙学习一下,并且在文档中不清楚)。作为不当使用的示例,我们有:

sample='{"myvar":1,"var2":"foo"}'
jq '{newVar: (.op[].item? // 0)}' <<< $sample

因此,由于 op null ,将导致错误,因为您告诉jq在检索 .item ,尽管提到了在尝试遍历 null (在本例中为 .op [] )期间出错的可能性,并且该尝试在此之前发生检查 .item 。 另一方面,在这种情况下,尝试会起作用

sample='{"myvar":1,"var2":"foo"}'
jq '{newVar: (try .op[].item catch 0)}' <<< $sample

这是一个很小的用途差异,可能会导致结果差异很大