假设有一个计算环境，Linux，它是静态的、持久的。我有单向 ssh 连接，并且基础设施是可信的——它是我的。
存在多种品牌的“企业”工具，例如 ansible，它带有预装例程。最终，如果有人想修改它们，它们会很痛苦。
接下来，您有气流 (dags) 和 Luigis（Python 中的 gnu-make 克隆；Python 是比 make 和 bash 更低级的语言，与 make 不同，没有应用程序二进制接口支持）。从某种意义上说，这是一种痛苦，因为人们必须为高级任务编写低级代码（Python 已经成为一种具有打字问题和版本控制问题的低级语言），并且您必须处理 Python 包袱（虚拟环境/ anaconda/跨平台互操作）以便使用任何东西。
围绕这些“产品”、方案和工具，存在“正常工作”的本机 unix/linux 操作系统和 docker 镜像。
在这些 docker 镜像和子系统（Linux 的 Windows 子系统）中，您拥有所有这些“正常工作”的工具，包括已有 50 年历史的项目“Make”，以及zsh/bash与.parallelssh
makeluigi事实上，它是完全通用的，当我想编写一些快速自动化程序时，它比我用/在一两周内所做的任何事情都要快得多airflow。它还可以作为识别新工具的一种方式：如果某件事变得太复杂，显然它应该是一个较低级别语言的打包工具。
此外，我不会因为在不同的 Linux 发行版和 Windows 之间拖动 Python 依赖项而产生任何固定成本。
然而，似乎缺少一个部分：当我想要自动化在远程机器上运行的任务时，make 的有效性就会减弱。我尝试过ssh -c "..."，但最终结果有点混乱。
在寻找解决方法的过程中，我遇到了pachyderm（数据科学数据版本控制），luigi（制作克隆），airflow（不好玩），ansible（再次：基于Python的修补时间接收器），也许还有其他。
我还遇到了 20 世纪 80 年代/90 年代的一个工具，称为expect和autoexpect。这个工具似乎是原生的linux，并且属于适用于 linux、cygwin、我的远程 Linux 机器等的 Windows 子系统上的“正常工作”类别。
它似乎符合要求，而且更好的是它与我make风格的自动化方法配合得很好。总的来说，我完全可以接受automation.exp脚本内部的噪音，因为它们是自动生成的。重要的是，人类创建的组件——这些小组件components.exp可以毫无杂乱地组合在一起（所有流程控制、配置、用户登录、文档和与新时代工具相关的安装包袱）。
然而，autoexpect它是一个宏记录器，您可能想要用它做的很多事情都涉及来自远程计算机的非确定性响应。这会带来一个问题，除非您花时间成为expect专家。
抛开所有的序言，我很好奇：是否有其他替代方案autoexpect也属于这些系统中的“公正”作品类别？
而且，为了限制显而易见的事情，不要让我的自动化系统要求我拖着机器来安装和维护 python 虚拟环境——厌倦了处理这些混乱。
答案1
对于远程执行，您可能需要查看env_parallel：
dostuff() {
mystuff "$@"
}
alias mystuff='echo $my'
my=My
env_parallel -S server dostuff ::: a b c
这里的想法是让 GNU Parallel 将环境复制到远程服务器。因此，可以更轻松地在本地服务器上定义复杂的函数并让它们远程运行，而无需处理您可能遇到的引用马戏团ssh -c "..."。
目前尚不清楚您是否需要 的交互性expect。如果是这样，这将不能满足您的需求。