---

背景

最近，我正在部署我自己的博客，因为使用的是obsidian，所以为了过滤隐私文件/转换wiki链接，我自己写了个Python程序来转换。

因为使用的Vuepress需要把图片文件放在Public文件夹下面，所以还写了个程序，用来把图片文件转移到.vuepress/public文件夹下。

本地运行，很完美，效果都实现了。要不部署看看吧。然后，.vuepress就不知道去哪了

开始Debug——怀疑Linux的问题

介于以前就因为Github Action就出现过因Linux的路径问题导致的BUG，所以先给所有的路径都加上一个os.path.normpath，希望能实现。

本地跑，完美。放到Action，还是不在。加一个ls，也找不到。

怀疑Python的问题

因为我的file_move写的很抽象，是这样写的:

with open(path1) as f:
    content = f.read():
path1.unlink()
with open(path2) as f:
    f.write(content)

因为一些莫名其妙的路径问题，所以只能用这种浪费IO性能的方式。 然后用Pycharm的debug调试了半天，还是改回了一般的移动方式

shutil.move(path1,path2)

本地运行，还是完美。但是Github Action还是跑不出来。 此时，因为长时间的调试，已经刷了10多个Commit，也红温了

初露端倪

既然还是路径的问题，那就加ls吧，狠狠的加。 不过没用。

但是为什么不试试在Python内ls一下呢（？ 直接叫出copilot写一个递归打印。 Amazing! 文件已经处理好了！都在处理好的文件夹安安静静的躺着呢。 但是目标文件夹依然找不到，Push后的仓库也找不到。

找到原因

经过一系列对ls，最终锁定到了一条语句上:

cp -r obsidian_data/* wait_publish_data/

看起来很正常，对吧？把obsidian_data内的所有文件移动到wait_publish_data。 但是，在两侧中，都是正常的。能处理文件的也只有这一条语句了。 随后就开始怀疑，怀疑*是否正常。立刻询问Github Copilot网页版（不得不说是真好用） 得到结论:

/*选中的是所有的文件，但是不包括隐藏文件和文件夹，例如.git和.vuepress，如果要选择的话，请使用/.以选择所有的文件

好，问题成功解决，只因为一个*。 但是代价呢？

红温了3小时