在 shell 脚本中将逗号分隔的命令行参数转换为 json答案

【问题标题】：convert comma separated command line arguments to json in shell script在 shell 脚本中将逗号分隔的命令行参数转换为 json
【发布时间】：2020-01-04 04:51:33
【问题描述】：

我正在使用以下脚本从逗号分隔值生成 json 数据以提供给 zabbix。但我得到了一个额外的逗号符号。请尽量优化最后一行的逗号。

#/bin/bash
IFS=':, ' read -r -a array <<< "$1"
idx=0
echo {\"data\":[
while [ -n "${array[$idx]}" ]; do
        echo -n \{\"{#R_IP}\":\""${array[$idx]}"\"}
        let idx=$idx+1
        [ -n "$array[idx]}" ] && echo "," || echo
done
echo ]}
exit

输入

./test.sh embimsrv.exe,emcms.exe,emcmsg.exe,emforecastsrv.exe,emgtw.exe,emguisrv.exe,emmaintag.exe,emselfservicesrv.exe,Naming_Service.exe,p_ctmce.exe,p_ctmcs.exe,p_ctmrt.exe,p_ctmtr.exe,p_ctmwd.exe

输出

{"data":[
{"{#R_IP}":"embimsrv.exe"},
{"{#R_IP}":"emcms.exe"},
{"{#R_IP}":"emcmsg.exe"},
{"{#R_IP}":"emforecastsrv.exe"},
{"{#R_IP}":"emgtw.exe"},
{"{#R_IP}":"emguisrv.exe"},
{"{#R_IP}":"emmaintag.exe"},
{"{#R_IP}":"emselfservicesrv.exe"},
{"{#R_IP}":"Naming_Service.exe"},
{"{#R_IP}":"p_ctmce.exe"},
{"{#R_IP}":"p_ctmcs.exe"},
{"{#R_IP}":"p_ctmrt.exe"},
{"{#R_IP}":"p_ctmtr.exe"},
{"{#R_IP}":"p_ctmwd.exe"},
]}

【问题讨论】：

逗号分隔确实是错误的做法。 shell（由用户调用您的脚本运行的，而不是运行脚本本身的）在空格上拆分命令行参数，遵守其引用规则；当你传递一个逗号分隔的列表时，这不会阻止 shell 先进行自己的拆分和其他处理。
...手工生成 JSON，也是错误的做法；你有比缺少的逗号更多的错误。使用真正的 JSON 生成工具/库，您的代码不会在您注入带有需要转义才能在 JSON 字符串中有效的字符的数据时中断。

标签： linux shell

【解决方案1】：

使用适当的工具（例如 jq）来生成 JSON。

printf '%s' "$1" | jq -R 'split(",") | map({"{#R_IP}": .}) | {data: .}'

【讨论】：

我今天没有票了，但为了记录，这也得到了我的支持，一旦我可以。

【解决方案2】：

像这样手动拼凑 JSON 非常脆弱。但是这里有。一个非常常见的技巧是前缀除了第一个字符串之外的每个字符串都使用逗号。

#!/bin/bash
IFS=':, ' read -r -a array <<< "$1"
prefix=''
printf '%s' '{"data":['
for item in "${array[@]}"; do
    printf '%s%s' "$prefix" "{\"{#R_IP}\":\"$item\"}"
    prefix=','
done
printf '%s\n' ']}'

还要注意脚本结尾处不需要显式的exit。 shell 停止执行脚本并在到达脚本末尾时终止。

另外，shebang 需要以两个单字节字符 #! 开头。

最后，一个更好的整体设计可能是不需要用逗号分隔参数；但我不会尝试在这里解决这个问题。

【讨论】：

一个简化（？）：将对象的固定部分移动到printf的第一个参数中，例如：printf '%s{"{#R_IP}": "%s"}' "$prefix" "$item"。这种方式并没有更好（或更差）地工作，但确实在生成的 JSON 的静态和动态部分之间提供了更清晰的分离。
对 OP 的警告：请务必注意 Charles Duffy 对该问题的第二条评论。