Stack项目中的stack upgrade命令对非默认命名可执行文件的处理问题

在Stack项目的使用过程中，开发者们发现了一个关于stack upgrade命令的有趣行为。当用户通过非默认命名的Stack可执行文件（如stack-x.y.z）运行升级命令时，该命令会直接覆盖原可执行文件，而不是像预期那样只更新默认的stack链接。

问题背景

Stack是一个流行的Haskell构建工具，它提供了stack upgrade命令用于升级到最新版本。按照官方文档的描述，当运行的可执行文件名为stack（或在Windows上的stack.exe）时，升级过程会替换该文件。然而，实际情况却有所不同。

在典型的GHCup安装环境中，stack通常是一个指向具体版本号命名的可执行文件（如stack-2.15.7）的符号链接。当用户通过这个版本化命名的可执行文件运行stack upgrade时，命令会直接覆盖原可执行文件，而不是只更新stack符号链接。

技术分析

这个问题源于Stack内部对可执行文件路径的处理逻辑。在代码实现中：

1. System.Environment.getProgName用于获取运行时的程序名称
2. System.Environment.getExecutablePath用于获取实际的可执行文件路径

当这两个值不一致时（如通过符号链接运行时），现有的升级逻辑没有正确处理这种情况。原本的设计意图是只覆盖默认命名的stack可执行文件，但实际上却覆盖了版本化命名的原始文件。

解决方案

经过社区讨论和代码审查，Stack项目已经修复了这个问题。新版本的实现会：

1. 检查实际运行的可执行文件名称
2. 如果名称不是简单的stack（包含版本号等额外信息），则默认使用--only-local-bin选项
3. 确保只更新默认的stack链接，而保留版本化命名的原始可执行文件

这个改进使得升级行为更加符合用户预期，特别是在使用GHCup等版本管理工具的环境中。用户现在可以放心地使用版本化命名的Stack可执行文件，而不用担心升级命令会意外覆盖它们。

最佳实践

对于Stack用户，特别是使用GHCup管理的环境，建议：

1. 尽量通过默认的stack命令运行升级
2. 如果需要保留特定版本，使用版本化命名的可执行文件
3. 升级时可以使用--only-local-bin选项明确指定只更新本地二进制文件

这个改进体现了Stack项目对用户体验的持续关注，也展示了开源社区如何通过问题报告和代码贡献来不断完善工具链的行为。