GitHub Desktop 团队,也是草台班子

在电脑里看到的最讨厌的事情之一就是有的程序/组件的重复。Chromium 的 CEF 最垃圾,但是惹不起啊,只能忍受,但是别的东东,有时候还是要抗争一下。

例如 git。好些个工具都自己带这个玩意儿,但又有好些个总是要检查系统里有没有现成的。既然这样,给你们合二为一不好吗?于是,俺就把 GitHub Desktop 自带的 git 放到了环境变量里。

好日子没过几天,某次突然发现在命令行里找不到 git 了。再一看,GitHub Desktop 升级了,它的安装路径下,有一个入口可执行程序,与之平级会有不止一个 app-x.y.x 的目录(很显然,x.y.z 是版本号),每个目录下都是一份完整的对应版本。一般来说,会总是保留最近的两个版本,大概是为了出了问题好回退。这样交替更迭几回,那么死守着旧版本的环境变量总归会失效,需要手动去系统设置里修改一下路径,把版本号改到最新的一版。烦。

于是请 WorkBuddy 来帮忙,让它写个批处理(本人一般不会动用 PowerShell 这种重器)。使用它这两天优惠着的 Space-Bunny 模型,好家伙,批处理里面的坑把它折腾的死去活来,整整迭代了九轮,才算出来个能用的,看了下大小,接近 20KB,是我这辈子产出的个头最大的批处理文件了。

思路特简单,就是在 app-x.y.z 平级创建一个名为 app-latest 的 Junction(这个单词把老夫搞住了,不知道怎么翻译,之前以为是软链接,但 AI 说不是),如果在命令行里找不到 git 了,就把批处理执行一下,没有这个 Junction 则创建之,有则更新之,而系统环境变量里永远是 latest 不需要改。

事情就是这么巧。昨天刚刚把批处理搞定,app-latest 创建好,也指向了最新的 app-3.6.6 目录,GitHub Desktop 工作正常。今天,就在刚刚,把窗口切换到 GitHub Desktop 时,突然弹框报错,说 git 找不到了。拿脚趾头想都知道跟俺昨天的移花接木小手术有关。那个弹框是源源不断的,鼠标点击永远点不完。这个时候要上手速,Alt-F4 连续按,症状消失。到安装目录里查看,果然 app-3.6.7 赫然在目。但这个时候,你如果运行安装目录里的入口程序,则没有任何效果,光标转一两秒后没有任何情况发生。但是,如果双进入到任一版本的目录中,再执行其中的可执行文件,GitHub Desktop 就会正常运行起来。

其实昨天写批处理的时候,跟 AI 已经就这个 Junction 的名字讨论过一番了,当时它害怕的是,GitHub Desktop 的升级程序会根据 app- 前缀来过滤出所有匹配的子目录,除去它自己标明为最新版的那个的话,其余的都会一概删除,而这里面一定会包括有 app-latest。老夫当时的逻辑是,app-latest 指向的不管是哪个版本,对于升级器来说一定是指向了一个旧版本,它删就删了。出于洁癖,命名依然定为 app-latest。但今天的铁定事实证明,入口程序也会被 app-latest 影响:因为当俺把 app-latest 的首字母改掉以后,入口程序就也可以加载到正确的最新版本而成功运行起来了。

看来还得退避一舍,把批处理里的 app-latest 改成别的名字,就叫 ghd-latest 吧。

尽管问题因咱而起,但正如题目所说,开发团队实在是也相当粗疏,app- 的前缀之后,好歹也该检查一下版本格式的。为了表彰 WorkBuddy 虽然资质一般但毕竟勤勤恳恳,把它生成的批处理附录于此。

发表回复

您的邮箱地址不会被公开。 必填项已用 * 标注