#WorkBuddy# 路径没报错却烂了：Git Bash 里跑 Windows 工具的三记闷棍

#WorkBuddy# 路径没报错却烂了：Git Bash 里跑 Windows 工具的三记闷棍

场景

我的自动化管线大量跑在 Git Bash 这类 MSYS 环境里：AI 助手通过它调用 ffmpeg、Python 和各种 Windows 工具。这个组合平时相安无事，但每隔几天就会出一次"灵异事件"——命令不报错，结果就是不对：路径悄悄烂掉、滤镜参数被改写、模型加载不到。今天连我自己截素材的时候都当场中了一招，干脆把这三记闷棍一起记录成册。

过程

第一棍：脚本字符串里的反斜杠，转义转出响铃。

我在 Python 一行命令里写 'D:\articles\log.txt'，输出看着"差不多对"，实际路径根本打不开。用 od -c 把输出按字节 dump 出来一看，实锤了：\a 被 Python 解析成了 07 响铃字符，路径变成了 D:<BEL>rticles\log.txt。最阴险的是它只警告不报错——Python 2 时代 \a 是合法转义，Python 3 会给个 SyntaxWarning，但很多人（包括我）的终端里警告一闪而过。解法很朴素：要么用原始字符串 r'D:\articles'，要么在拼接场景用 chr(92) 显式拼反斜杠，让转义彻底失去发生的机会。

第二棍：参数里的盘符冒号，被 MSYS 半路改写。

给工具传 C\:/models/sh.rnnn 这种带转义冒号的参数（ffmpeg 滤镜串里常见这种写法），MSYS 会自作聪明地做路径转换。实测拿 Python 把收到的 argv 原样打印出来，真相触目惊心：参数被改写成了 <Git安装目录>/models/sh.rnnn 还附加了盘符前缀——我的相对引用被换成了它自己的安装路径。命令照常执行，工具照常报"模型不存在"，你却对着参数检查八遍都看不出毛病，因为你写的和你以为传的是两回事。

第三棍：正斜杠开头的参数，被当成 Unix 绝对路径翻译。

同理，/models/sh.rnnn 会被翻译成 Git 安装目录下的路径。MSYS 的本意是兼容 Unix 习惯，但在这个场景里就是帮倒忙。

解法

三棍的共同解法是一个思路：别让敏感路径经过命令行转换层。

1. 给外部工具设置固定的 WorkingDirectory（工作目录），所有引用改用相对路径——相对路径没有盘符、没有开头斜杠，MSYS 没有下嘴的地方；
2. 必须在字符串里写 Windows 路径时，用 chr(92) 拼接或原始字符串，杜绝转义；
3. 拿不准时，用 sys.argv 的 repr() 打印实际收到的内容——眼见为实，这一招每次都能立刻定位是"我写错了"还是"它改了我的"。

总结

在 MSYS 环境里跑 Windows 工具，记住三句话：

1. 不报错不等于没坏：路径类损坏往往是静默的，关键路径要用字节级手段（od -c）验证；
2. 命令行是公共汽车：经过它的参数都可能被改写，敏感路径要么坐工作目录的"专车"（相对路径），要么提前验证送达结果；
3. repr 是照妖镜：一个 print(repr(sys.argv[1])) 值得写进所有调试脚本的第一行。

附上本次实测的关键命令，可直接复制：

:: 1. 字节级验证: 看路径里有没有混进控制字符
python -c "print('D:\articles\log.txt')" | od -c

:: 2. 参数照妖镜: 打印程序实际收到的内容
python -c "import sys;print(repr(sys.argv[1]))" "你的参数"

:: 3. 根治: 固定工作目录 + 相对路径引用
ffmpeg -working-directory C:\ScreenRec ... -af arnndn=m=sh.rnnn

三记闷棍换来的就这一句：在转换层面前，永远验证你实际递出去的东西。