@irisdev 收到，感谢。我回去试试

@Trello oh my posh ，跟 oh my zsh 差不多

@ijammy 因为当时下载软件的时候 在墙内 访问 github 已经很难了

再次重启了下 /etc/resolv.conf 里就恢复正常了

@lEONiNv2 本身就没勾选😭

@nijjba 空的，啥都没勾选。
网上流传的 在网络里添加一个新位置应该就是为了“重置”这个代理设置

@linuxsteam 为啥少输出一次就不会阻塞了 的问题也不用回复了
我明白了： 因为 err 一直在写，进程没有结束 所以就阻塞了

@senninha 是的，24 楼那个我已经试过了。可以通过。。。诶 我看了两本操作系统的书 进程通信中管道章节。都没有找到大佬您说的这几个关键点😭

@senninha #27 楼请忽略。。。 这个看不看已经没有必要了😂

@haah 我想研究研究，这个源码也有在看。
@senninha #24 可以了😭
#26 谢谢大佬，进程终止才会发 eof 这个和 JDK 的 API 的 readBytes()注释对上了 😭
小弟还有两个问题
1. 请问 子进程和父进程通信时候，stdout stdin stderr 他们要开三个管道吗？还是一个管道就可以？
2.
```shell
echo "input"
for((i=0; i<10912; i++));do
# 输出到 stderr
echo "error" 1>&2
done
```shell
为啥少输出一次就不会阻塞了？

@senninha
#20
https://pastebin.com/0cVtyGCr
老哥能看看这个结果吗 这个 gdb 的资料真是太少了。。。

@senninha ```shell
#!/bin/bash

# 输出到 stdin
echo "input"
for((i=0; i<10913; i++));do
# 输出到 stderr
echo "error" 1>&2
done
```

#19 stdout 什么时候才算结束？
这个例子就一个 stdout ，
为啥还会卡在循环中？

@zmal 跟 read 没关系 他们底层都是调用 FileInputStream 的 private native int readBytes(byte b[], int off, int len)

@Bingchunmoli 解决方案我了解的。
除了这个方法 还可以把标准错误流 重定向到一个流中，这样单线程也可以

@AoEiuV020CN 谢谢大佬的讲解，我受到了大佬的点播，终于不研究是底层问题了

在网上找到了答案，是因为 readLine()没有返回 /r /n /r/n 或者 EOF
https://www.cnblogs.com/firstdream/p/8668263.html

@thetbw 在阻塞前，available()返回的是 0
我把脚本减少 for 循环次数，最后一次输出 input 的时候 avaliable()返回还是 0

@AoEiuV020CN
```shell
#!/bin/bash

# 输出到 stdin
echo "input"
for((i=0; i<10913; i++));do
# 输出到 stderr
echo "error" 1>&2
done
echo "input"
```

那怎么解释这个在 java 中就输出一行
1 input 呀

按道理应该是 stdin 完事，stderr 流继续呀。
最后一个 input 也没输出出来。因为在 java 程序里 卡在了 readLine()

@AoEiuV020CN 这个是解决办法，但是为啥缓存区满了 java 的 readLine()就无法读取了呢？ 书上只给了这个结论。刚刚看源码，Java 是卡在 BufferedInputSteam.read1(byte[] b, int off, int len) 中 getInIfOpen().read(b,off,len);这里
这个 getInIfOpen()返回的就是 PipeInputSteam ，是印证了结论。但是我还是蒙😂

@forbreak @zmal
- 是有一部分的原因 导致阻塞在 readLine()
> 我把 readStreamInfo(process.getInputStream(), process.getErrorStream()); 注释掉就可以把代码跑到 waitFor()
waitFor()会等待子进程结束，实际情况是卡在这里。也就是说没卡在 readLine() 卡在子进程没有结束了

但是我把 shell 脚本的循环次数调整成 10911 readLine()也不阻塞了。
这就让我感觉与 \r \n EOF 无关了