TTY与CI

标题：当车载编译容器非要“人工陪聊”：tmux如何让自动化脚本当“隐形操作员”

一、引子：那个非要“人盯着才能干活”的编译容器

最近在给车载监控系统写自动化编译脚本时，被一个叫make test_in_vehicle_compiler的命令折磨得够呛。这命令的作用是拉取一个“编译容器”，启动后会自动进入容器内的交互式shell——按设计，用户本该在这个shell里手动敲make prepare（准备依赖）、make build（编译镜像），最后exit退出。

但我的目标是“全自动化”：让脚本启动容器后，自动在里面跑完prepare→build→exit，全程无人干预。结果发现，这容器是个“粘人精”：

• 直接make test_in_vehicle_compiler &后台启动？容器启动到一半就“自闭”了——交互式shell检测不到终端，直接报错interactive shell requires a tty，进程退出。
• 用docker run -d ...启动容器再exec命令？容器内的shell根本没进入交互模式（因为没TTY），docker exec进去敲make prepare，直接返回no job control in this shell（非交互shell不支持作业控制）。
• 试了expect脚本模拟输入？容器启动时的make test_in_...会先跑一堆初始化脚本，交互时机飘忽不定，expect经常“答非所问”，像个没睡醒的接线员。

直到扔出tmux new -d 'make test_in_vehicle_compiler'，再用tmux send-keys往会话里“塞命令”，居然成了：容器内的交互式shell乖乖待着，make prepare、make build按顺序执行，最后自动退出。那一刻突然懂了：tmux不是简单“后台运行工具”，而是给自动化脚本安了个“能钻进容器里打字的隐形手”。

二、先拆透：为什么这个编译容器非要“交互式shell”？

要搞懂问题，得先看这个车载编译容器的“工作模式”。它本质是个“带交互界面的编译工作台”，启动流程藏着两个关键设计：

1. 容器启动后会强制进入交互式shell：比如docker run -it --rm vehicle-compiler /bin/bash（-it是关键，-i打开交互，-t分配TTY），这会让容器内的bash进入“等待输入”状态——就像前台接待员：“请说出您要办的业务（命令），我等着呢”。

2. 编译命令依赖“交互shell环境”：make prepare需要读取shell的环境变量（比如$TERM终端类型），make build在编译时会实时输出进度条（依赖终端尺寸信息），这些都需要shell处于“交互式模式”（非交互式shell会关闭很多终端特性）。

这里的核心矛盾是：自动化脚本需要“无人干预”，但容器内的交互shell和编译命令，却依赖“有人在场”（即存在TTY）才能工作。普通后台方式要么“赶跑了在场的人”（没TTY），要么“没法替人说话”（无法向交互shell注入命令）。

三、普通方法在“交互shell场景”里的囧态：像隔着玻璃指挥前台

在这种“容器内有交互shell，需要自动输入命令”的场景里，常规手段的操作堪称“技术版隔靴搔痒”：

1. nohup make test_in_vehicle_compiler &：把前台接待员关进小黑屋

nohup能让make进程在终端关闭后继续跑，相当于“把接待员锁在办公室不让走”。但它会把进程的标准输入重定向到/dev/null，容器内的bash执行isatty(0)（检查是否有终端）时，发现“办公室门被焊死了（没TTY）”，直接拒绝进入交互模式——要么启动失败，要么进入非交互shell（bash --norc模式），make prepare会因为“找不到终端特性”报错（比如进度条输出失败）。

2. docker run -d vehicle-compiler 'make prepare && make build'：跳过接待员直接办业务

这种“直接在容器启动命令里塞编译命令”的思路，看似聪明，实则忽略了容器的设计逻辑：vehicle-compiler镜像的ENTRYPOINT是/bin/bash，必须先进入交互shell，才能加载/etc/profile里的车载编译环境变量（比如SDK_PATH、HARDWARE_TYPE）。直接跑make prepare会因为“环境变量缺失”失败，就像“跳过前台直接冲进办公室，发现抽屉全锁着（没加载环境）”。

3. expect脚本：想当“提词器”，却总跟不上接待员的节奏

expect能模拟用户输入，但在嵌套场景里很容易“翻车”：make test_in_vehicle_compiler会先拉取10分钟镜像，再花2分钟初始化硬件配置，最后才进入bash——expect的“等待交互提示符”逻辑（expect "# "）很容易因为“等待超时”或“中间输出干扰”误判，要么提前发送make prepare（发早了，被初始化日志吞了），要么一直等不到提示符（卡成死机）。

四、tmux的“双buff技能”：既当“在场的人”，又当“代打操作员”

tmux能解决问题，核心是它同时搞定了两个关键需求：给交互shell一个“在场的理由”（提供TTY），又能“替人说话”（向shell注入命令），堪称“自动化脚本的替身演员”。

1. 第一重buff：tmux new -d给交互shell一个“永久开放的办公室”

当你执行tmux new -d -s vehicle_build 'make test_in_vehicle_compiler'时，tmux会：

• 创建一个独立会话，并分配一个虚拟TTY（比如/dev/pts/20），相当于“给接待员（交互shell）留了一间永远不关门的办公室”；
• make命令启动的容器会继承这个TTY，容器内的bash执行isatty(0)时返回true，乖乖进入交互模式（显示root@vehicle-compiler:/# 提示符），不会因为“没人在场”而罢工。

2. 第二重buff：tmux send-keys替你向shell“发号施令”

tmux的send-keys命令能往会话里“模拟键盘输入”，完美解决“向交互shell注入命令”的问题。比如：

# 启动会话，让容器进入交互shell
tmux new -d -s vehicle_build 'make test_in_vehicle_compiler'

# 等30秒（确保容器启动并进入shell，根据实际情况调整）
sleep 30

# 向shell发送"make prepare"并回车
tmux send-keys -t vehicle_build "make prepare" C-m

# 再等10秒（等prepare完成）
sleep 10

# 发送"make build"并回车
tmux send-keys -t vehicle_build "make build" C-m

# 最后发送exit退出容器
sleep 60
tmux send-keys -t vehicle_build "exit" C-m

这里的关键是：容器内的bash在tmux提供的TTY环境中，会把send-keys的输入当成“真实用户敲的键盘”，乖乖执行命令——因为交互shell的“安全感”来自TTY的存在，至于输入是“人敲的”还是“tmux发的”，它根本不关心。

3. 为什么这招比expect靠谱？

expect依赖“捕捉交互提示符”，而tmux根本不关心“提示符什么时候出现”——它只是“在TTY里按顺序打字”，就像你在键盘上按顺序敲命令，哪怕中间有延迟，只要shell最终进入交互模式，命令总会被接收。对于车载编译这种“启动慢、输出乱”的场景，这种“傻等+硬发”的方式反而更稳定。

五、实战：给车载自动化脚本加tmux的“标准操作流”

结合车载编译容器的特性，脚本里可以这样写，兼顾稳定性和可调试性：

# 1. 启动tmux会话，启动容器并进入交互shell
tmux new -d -s vehicle_test 'make test_in_vehicle_compiler'
echo "容器启动中，等待初始化..."

# 2. 用tmux wait-for确保会话就绪（比sleep更可靠）
# 等待容器内出现"root@vehicle-compiler"提示符（表示进入shell）
tmux send-keys -t vehicle_test "echo 'ready'" C-m  # 发送一个标记命令
tmux wait-for -t vehicle_test -S ready_signal  # 等待标记出现
echo "容器已进入交互模式，开始自动编译..."

# 3. 依次注入编译命令
tmux send-keys -t vehicle_test "make prepare" C-m
sleep 10  # 可根据实际编译时间调整

tmux send-keys -t vehicle_test "make build" C-m
sleep 60

# 4. 退出容器并关闭会话
tmux send-keys -t vehicle_test "exit" C-m
sleep 5
tmux kill-session -t vehicle_test

echo "自动化编译完成！"

这种方式的妙处在于：就算中间某个步骤卡住，用tmux attach -t vehicle_test就能“亲临现场”，看到容器内的实时输出（比如make build卡在哪一步），比黑盒调试高效多了。

六、总结：tmux的本质是“给交互流程搭了个自动化舞台”

解决这个问题后我才明白：像车载编译容器这种“依赖交互shell的场景”，核心需求不是“后台运行”，而是“在保持交互环境的同时，实现命令自动化”。

tmux的价值，在于它不是“破坏交互”，而是“模拟交互”——通过虚拟TTY让交互程序“以为有人在场”，再通过命令注入“替人完成操作”。这就像给自动化脚本配了个“带终端的隐身衣”，既能骗过需要TTY的程序，又能在里面自由操作。

说到底，技术工具的厉害之处，往往不是“对抗规则”，而是“利用规则”——tmux就是那个最懂“交互程序规则”的帮手。