1 回答
TA贡献1824条经验 获得超8个赞
关于 OP 源代码,我会考虑更改条件以检测管道的存在。
正确的条件不需要检查输入的长度。考虑一下,这完全是有道理的,因为您可以在不写入数据的情况下打开标准输入。
除了所提出的解决方案对于它试图实现的目标而言似乎毫无用处的复杂性,json 输入的漂亮打印。
我发现使用标准库足以实现给定测试用例的目标。
关于这个问题...but how do I optimize my Go program to wait until curl is done?
,OP 似乎不了解文件描述符的工作方式。事实上,这个问题甚至都不正确,因为该进程理论上可以保持活动状态但主动决定关闭 Stdin。OP 对进程的活跃度不感兴趣,相反,他应该在读取 Stdin 时简单地寻找 EOF 信号,表明感兴趣的数据已正确发送。
无论如何,一个简单的解决方案看起来像这样,用 json 解码器包装 stdin,循环直到 eof 或发生错误,对于每个解码数据,用 stdout 的包装器将其编码为 json,再次出现错误中断。
package main
import (
"encoding/json"
"fmt"
"io"
"log"
"os"
)
func main() {
info, err := os.Stdin.Stat()
if err != nil {
log.Fatal(err)
}
if info.Mode()&os.ModeCharDevice != 0 {
fmt.Println("The command is intended to work with pipes.")
fmt.Println("cat file.json | prettyjson")
return
}
dec := json.NewDecoder(os.Stdin)
enc := json.NewEncoder(os.Stdout)
enc.SetIndent("", " ")
for {
data := map[string]interface{}{}
if err := dec.Decode(&data); err != nil {
if err == io.EOF {
break
}
log.Fatalf("decode error %v", err)
}
if err := enc.Encode(data); err != nil {
log.Fatalf("encod error %v", err)
}
}
}
- 1 回答
- 0 关注
- 100 浏览
添加回答
举报