Linux tsort 怎样识别依赖关系中的循环

将依赖关系写成“前置任务 后续任务”的空白分隔字符串对，交给GNU tsort即可检查能否拓扑排序。检测到循环时，它会向标准错误输出诊断并以非零状态退出。即使标准输出里出现了任务名，也不能把失败调用的输出当成满足全部依赖的顺序。

官方地址：https://www.gnu.org/s/coreutils/manual/html_node/tsort-invocation.html

确定小项目范围与工具

这个小项目只做一件事：接收文本依赖清单，成功时展示候选顺序，失败时保留诊断并停止。它不执行清单里的任务，不调度并发作业，也不修改systemd服务或挂载配置。

示例面向Linux上的GNU Coreutils实现。读者可先用tsort --version识别工具；不同系统同名命令的扩展和诊断细节可能不同，不应直接套用另一实现的选项。下面代码是供读者复现的示例，未在本文环境执行；预期判断来自官方契约与输入关系分析。

定义依赖字符串对的方向

约定collect代表收集，normalize代表规范化，pack代表打包，publish代表交付。输入中的collect normalize表示collect必须排在normalize之前。tsort处理的是字符串及其偏序约束，不知道这些任务的实际业务含义。

建议一行只写一对便于复查，但解析单位是空白分隔的成对字符串，不是带字段含义的CSV。名称中不要嵌入空白，也不要把Shell引号或注释当作清单格式的一部分；引号写进数据文件不会让tsort自动理解带空格的任务名。可读名称需要另外映射为不含空白的稳定标识。

构造成功与循环输入

# 在新建的演示目录中执行，避免覆盖业务文件。
mkdir tsort-demo
cd tsort-demo || exit 1
# 每行一对，左侧是前置任务，右侧是后续任务；printf生成纯数据。
printf '%s\n' 'collect normalize' 'normalize pack' 'pack publish' > deps.txt
# 制造闭环：publish又被声明为collect的前置条件。
printf '%s\n' 'collect normalize' 'normalize pack' 'pack publish' 'publish collect' > cyclic.txt
# 仅查看工具信息，不更改系统配置。
tsort --version

deps.txt中的四个任务是一条简单依赖链，其约束要求collect、normalize、pack、publish按这个相对次序排列。cyclic.txt再加入publish collect后形成闭环：每个任务都要求循环中的另一个任务先满足，所以不存在满足全部约束的线性顺序。

这里的循环由关系定义而来，并不意味着某个任务程序内部死循环。诊断时先核对输入对是否写反，再看业务是否真的互相依赖。单纯调换文件中的行顺序无法消除同一组依赖里的闭环。

在脚本中保留诊断和退出状态

把下面内容保存为check-order.sh，在演示目录中分别把deps.txt和cyclic.txt作为参数传入。脚本将标准输出保存在order.candidate，将标准错误保存在order.diagnostics；这两个文件每次调用都会覆盖，因此目录必须由当前调用独占，并发任务应各用自己的目录。

#!/bin/sh
# 用法：sh check-order.sh ./deps.txt；输入只作为数据，不执行其中名称。
if [ "$#" -ne 1 ]; then
    printf '%s\n' '请提供一个依赖清单文件' >&2
    exit 2
fi
# 从标准输入读取，避免把以短横线开头的文件名误当作选项。
# 两份输出都是本次候选结果；工作目录应为该次调用独占。
if tsort  order.candidate 2> order.diagnostics; then
    # 只在tsort成功后展示候选顺序，调用方仍需定义业务执行方式。
    cat order.candidate || exit 1
else
    status=$?  # 立即保存tsort或重定向失败的退出状态。
    cat order.diagnostics >&2
    printf '%s\n' '依赖顺序不可用，请修复输入或读取错误' >&2
    exit "$status"
fi

成功条件是tsort退出状态为0；循环输入预期进入失败分支。非零状态也可能来自文件读取、输入格式或工具执行错误，不能把所有失败都命名为“发现循环”。应读取诊断内容进一步判断。本文不展示伪造的错误输出，也不承诺某一版本的具体诊断顺序。

要点是直接在if条件中调用tsort，失败后立即保存状态。不要先执行其他命令再读取$?，也不要只检查候选文件是否非空。若直接把tsort管道传给后续命令，在没有明确管道状态策略时，后续命令成功可能掩盖前面的失败。本例先保留输出，确定成功后才展示。

修复关系并明确能力边界

对于示例闭环，应回到“交付为何成为收集前置条件”这个业务问题。若这条关系是录入错误，纠正原始清单；若它表达的是下一轮收集，应把轮次作为不同任务标识或重新设计任务模型。不要为了让命令通过随手删边，否则得到的只是被削弱的约束。

实际集成时，保留输入清单、工具版本和诊断有助于重现问题；工作目录应避免共享固定文件名。本例只展示结果，不把任何任务名当Shell代码运行。若要接入业务执行器，应使用明确的任务映射与权限约定，不能直接把输出交给eval。

成功排序一定只有一种吗？

不一定。没有相互约束的任务可以处于不同位置。应比较每条依赖是否满足，而不是把某一个文本排序当作所有输入唯一正确的答案。

tsort会直接找出所有业务错误吗？

不会。它只理解提交的关系；漏写依赖或把业务方向整体写反，仍可能得到合法拓扑顺序。语义正确性要由清单生成方负责。

能从退出码知道循环的数量吗？

本文按GNU手册使用0成功、非零失败，不把非零数值当作循环计数，也不根据诊断自动删除关系。

参考：GNU tsort 官方手册