tmux 确实很强大。
但一涉及到终端自动化，不少人还是得靠 grep 和 sleep 硬生生地拼凑流程。
有人实在忍不下去了，干脆从零写了一个不到 5MB 的小工具。
两周后，这个名为 rmux 的项目，在 GitHub 上斩获了 1300 个 Star。
它是一个专门用来解决终端自动化难题的工具。
用过 tmux 的人基本都懂它的好：多窗口、断线不中断，做远程开发极其顺手。
但一旦想让脚本去自动操作终端，画风就完全变了。
通常你得折腾这么一套流程：
发送命令，随后 sleep 等待，接着抓取屏幕输出，再用正则去“猜测”结果，然后才能进行下一步。
整个过程，就像在门外不停地敲门问：“好了没？好了没？”
rmux 想突破的，恰恰就是这件事。
rmux 的做法是直接装了个门铃——任务完成，它自己会通知你。
先看个小白例子
假设你想写个脚本完成以下任务：
自动登录到服务器，跑一个测试，等测试完成，拿到结果，然后发通知给你。
01 用 tmux 的话，你大概得这么写：
sleep(3) —— 这个 3 秒到底是怎么定出来的？纯粹是凭感觉猜！
网络要是快，就白白浪费时间；网络慢了呢，命令还没执行完，你就已经开始捕捉屏幕了。
sleep(10) —— 在实际测试中，有时 5 秒就跑完了，有时却要耗上 30 秒。你永远没法把它定得十分准确。
re.search —— 你得用正则表达式，在一堆乱码里去匹配结果，哪怕少了一个空格，都可能匹配不上。
02 用 rmux 则可以这样写：
我用一张图来做个对比，一目了然。
用大白话概括：
用 tmux 做自动化好比盲人摸象，而用 rmux 则是在睁眼开车。
最大的改变是什么？
01 不再靠猜，而是靠等
以前写 tmux 自动化脚本，最折磨人的就是估算等待时间。
等得太短，命令可能还没跑完；等得太长，不仅浪费时间，还不一定准。
rmux 直接用 wait_for_text("ready") 这样的指令。
你只需告诉它“等到出现 ‘ready’ 这个词就继续”，它便会老老实实守在那里，一出现就立刻通知你。
完全不用 sleep，也不用瞎猜。
02 能直接读懂屏幕上的字
tmux 抓到的屏幕内容多半是含有一堆 escape 序列的“乱码”，必须由你自己去解析。
而 rmux 会直接告诉你：第几行、第几个字符具体是什么字，用了什么颜色、什么样式。
这感觉就像是你直接看懂终端上显示的本来面目，而不是攥着一把原始数据去慢慢揣摩。
03 写代码就像操作浏览器
用过 Playwright 的朋友，应该一眼就能看出异曲同工之妙。
做个类比：
- 连接终端，就好比打开浏览器。
- 发送命令，相当于点击按钮。
- 等待结果，类似于等待页面加载完毕。
- 读取状态，则像是直接去读页面上的文字。
把这种“等它好了再下一步”的模式，搬到了终端里。
04 Windows 用户终于有救了
这一点对 Windows 用户尤其重要。
以往想在 Windows 上用个好用的终端多路复用器，要么得装 WSL（Linux 子系统），要么就得依赖各种兼容层，常常折腾半天。
rmux 直接提供了原生的 Windows 支持，不需要虚拟机，也不需要任何兼容层，装好就能用。
对那些每天在 Windows 上敲代码的朋友来说，这还是头一回有一个正儿八经的终端工具能直接跑起来。
05 连 htop 这种界面都能自动化
rmux 不只能自动化命令行，还能自动化界面程序。
用过 htop、lazygit 这类工具就会明白，它们并不是简单地输入命令然后输出结果。
它们属于那种带界面的、需要用键盘上下左右导航的程序。
传统的自动化方式很难应对这类工作，但 rmux 可以观察到这些程序的界面状态，然后模拟按键去操作它们。
这意味着：你几乎能够自动化终端里的所有东西，而不再局限于简单的命令行工具。
特别是在多 Agent 协调与复杂任务编排方面，rmux 展现出了强大的潜力：
看完这些功能，估计不少朋友已经想上手试试了
Mac 和 Linux 用户，直接用下面这一行命令就能安装：
curl -fsSL https://rmux.io/install.sh | sh
Windows 用户呢，打开 PowerShell，复制并执行这条命令：
irm https://rmux.io/install.ps1 | iex
要是你不想用命令行安装，也可以直接去下载安装包。
用起来和 tmux 非常类似：
rmux new-session -d -s work
rmux split-window -h -t work
rmux send-keys -t work 'echo "hello from rmux"' Enter
rmux attach-session -t work
用过 tmux 的朋友，上手几乎是零成本。
写在最后
rmux 确实是个好东西，但也别把它神化了。在日常使用场景下，tmux 会显得更稳定、更成熟一些。
毕竟 rmux 才刚刚起步。
要是你平时工作中 tmux 用得少，手动操作终端就已经完全够用，没必要再搞个 rmux。
但如果你希望让终端去干自动化的活儿，想让 AI 帮你操作终端，想用程序化的方式去读取终端状态，那 rmux 绝对值得你一试。
毕竟，能让程序员省下时间的工具，都值得我们鼓励。
这个项目基于 MIT 或 Apache-2.0 双协议开放。感兴趣的同学，可以直接去它的 GitHub 仓库 查看源码和文档。
发表于 2 小时前
|
查看: 3|
回复: 0
