大括号内命令在当前bash还是Telnet终端运行？管道前后命令是否同时启动？

大括号内命令的运行位置 #

大括号包裹的命令组运行在当前bash派生的子shell中，不会在telnet打开的远端终端会话里执行。
你写的这段代码的逻辑是：

{
sleep 2
echo "root"
sleep 2
echo "password"
} | telnet 192.168.1.11

管道符会把左侧命令组的标准输出，重定向为右侧telnet进程的标准输入。telnet进程拿到这些输入内容后，会把内容转发给远端的telnet服务端，本质是用脚本输出模拟人工敲入用户名、密码的操作。
默认bash配置（未开启lastpipe选项）下，管道两侧的命令会被当前bash分别fork为独立的平级子进程，二者不存在从属关系，左侧命令组根本没有进入telnet建立的远端交互会话。

管道符两侧命令的启动时机 #

管道符连接的所有命令是几乎同时启动的，不存在“前一个命令完全执行完才启动后一个命令”的逻辑，你之前对find . -type f | du -sh的认知存在偏差。
你会产生“du等find跑完才启动”的错觉，是管道的缓冲机制导致的：

• 管道的数据传递依赖内核开辟的固定大小缓冲区，左侧命令往缓冲区写数据，右侧命令从缓冲区读数据；缓冲区写满时左侧写操作会阻塞，缓冲区读空时右侧读操作会阻塞。
• 执行find . -type f | du -sh时，du进程会立刻启动，持续从管道读取find输出的文件路径、累计统计数据，直到find执行完毕、管道写端被关闭，du读到EOF信号才会停止读取，输出最终的统计结果。整个过程里du不是等find结束才启动，只是一直在等待输入、处理数据，最后才输出结果而已。

你可以用一行简单的命令验证这个逻辑：

sleep 5 | echo "右侧命令已启动，没有等左侧sleep执行完"

敲下回车后你会立刻看到echo的输出，完全不会等5秒，足以证明管道两侧命令是同时启动的。
你写的telnet脚本里加sleep等待，也正是因为两边同时启动：telnet刚发起连接时，远端还没返回用户名、密码输入提示，立刻发送输入内容会因为时机不对匹配不上提示，导致登录失败，加sleep就是等远端的交互提示加载完成，再发送对应的输入内容。

内容的提问来源于stack exchange，提问作者John