yes命令通过管道向目标命令持续输出“y”换行，但仅当目标命令实际从标准输入读取确认时才生效；若命令自带-y参数或交互逻辑不依赖stdin（如调用tty设备），则yes无效。
直接用 yes 管道传参就能自动确认，但必须注意目标命令是否真正读取标准输入（stdin）——很多看似交互的命令其实根本不吃 yes 的输出。
为什么 yes | command 有时完全没反应？
根本原因在于：不是所有“需要确认”的命令都从 stdin 读取输入。比如 rm -i、cp -i、apt install（未设环境变量时）确实会阻塞等待 stdin 输入；但像 yum install -y 或 apt-get install -y 这类自带 -y 参数的命令，压根不读 stdin，yes 对它们完全无效。
常见误判场景：
-
yes | yum install nginx→ 依然卡在 GPG key 导入提示（因为 yum 在 key 验证阶段才真正读 stdin，而-y才能跳过） -
yes | apt update && apt install foo→apt update不需要确认，apt install默认仍会问，但更推荐用DEBIAN_FRONTEND=noninteractive apt install -y -
yes | ./install.sh→ 如果脚本内部用read -p且未重定向 stdin，才有效；若用了dialog或直接调用tty设备，则失效
怎么判断一个命令能不能被 yes 自动确认？
最可靠的方法是手动运行一次，看提示是否出现在终端并等待你敲回车或 y/n —— 如果提示后光标停住、无其他输出，说明它在读 stdin；如果提示一闪而过或直接报错，则大概率不走 stdin。
实操建议：
- 先试
strace -e trace=read,write ./install.sh 2>&1 | grep read，观察是否对fd 0（即 stdin）有read()调用 - 临时把命令改成
yes | timeout 3 ./install.sh，看是否在 3 秒内退出或卡住 - 检查命令文档，搜索 “interactive”、“prompt”、“stdin” 等关键词
yes n 和 yes "" 不能替代 yes
yes n 会无限输出 n 换行，但多数确认逻辑只认 y、Y、yes 等，n 往往触发拒绝路径；而 yes "" 输出空行，很多程序会当作无效输入或直接忽略，甚至导致脚本崩溃（如某些 read -r 未设默认值时）。
更安全的做法：
- 确认要答
y：直接用yes（无参数），输出纯y换行，兼容性最好 - 确认要答
yes（全拼）：用yes yes，注意中间无空格 - 确认要答
y但怕干扰后续命令：加head -n N限流，例如yes | head -n 5 | command，避免多按了确认
替代方案比 yes 更稳定
当 yes 不生效时，优先考虑命令原生支持的非交互开关：
-
rm -f替代yes | rm -i -
apt install -y或DEBIAN_FRONTEND=noninteractive apt install -
yum install -y或dnf install -y - 脚本里用
export INPUTRC=/dev/null+yes | command可绕过某些 readline 行为
真正难搞的是那些硬编码了交互逻辑、又没提供开关的私有脚本——这时候 yes 是最后手段，但得配合 timeout 和日志捕获，否则可能卡死进程。
