切换到 hvm 并将我的脚本转换为与 Hugo 的 macOS 打包功能兼容。
直到几天前，在 macOS 上使用Hugo静态网站生成器的用户每次下载新版本时都不得不面对苹果的隔离机制。但随着 Hugo 0.153.0的发布，这种情况终于结束了。对于大多数 macOS 版 Hugo 用户来说，这无疑是件好事。但对于像我这样一直通过脚本管理 macOS 版 Hugo 工作流程的极客来说，这却……相当复杂。不过，在 Hugo 一位核心成员的大力帮助下，我也成功地让这种“新常态”对我来说变得有利可图。
应对包装变更
Hugo 0.153.0 更改了 macOS 的安装方式。以前二进制文件位于tar.gz压缩包中，现在则以标准的 macOS .pkg文件形式提供，只需双击即可安装。不过，它仍然是一个终端应用程序，因此不像典型的 macOS 图形界面应用程序那样容易更新，后者通常带有“检查更新”菜单项和相关功能。
我在 Hugo Discourse 论坛的一篇文章—— “macOS 版 0.153.0：使用 .pkg 而非 .tar.gz” ——中提问：“对于我们 macOS 用户来说，今后处理版本更新的最佳实践是什么？”一位用户建议我使用 Hugo 贡献者Joe Mooring维护的hvm （Hugo 版本管理器）工具；但是，当我尝试使用后发现它尚不支持这种新的打包方式。Mooring 在看到我的报告后，建议我在 hvm 的代码仓库中提交一个相关的 issue，我照做了。
同样在 Hugo Discourse 的讨论中，Hugo 维护者 Bjørn Erik Pedersen 解释了打包方式改变的原因：
人们一直以来都要求提供签名和公证的 [macOS 版本]……而且由于苹果公司加强了这方面的安全措施（你需要手动进入安全偏好设置，并将任何未经签名/公证的应用程序列入白名单），所以我决定是时候认真对待这件事了，这意味着要么使用 pkg 文件，要么使用 dmg 文件，而 pkg 文件要好得多。
我立即回复：
哦，请不要误会……——我觉得这是个好主意。我主要是想弄清楚以后如何在本地更新它。（我之前的方法是删除旧版本并拉取当前版本，使用
xattr -dr com.apple.quarantine命令作为解决您提到的问题的权宜之计。）
在我提交的 hvm 问题报告中，我和 Mooring 讨论了这个问题以及最佳解决方案。仅仅四天后——显然，这期间他还买了一台自己的 Mac！——他就把 hvm 更新到了0.9.0版本，这个版本能够兼容新的软件包。由于 hvm 只需几个简单的按键就能安装和使用新版本（也可以根据需要删除旧版本），这彻底解决了我的后续更新问题。
修改我自己的脚本
现在，我唯一剩下的问题就是我自己的脚本，在此之前的几年里，我一直通过脚本来管理我的本地 Hugo 操作。
在 Hugo 0.153.0 版本之前，我曾经编写过一个install.sh脚本，它会下载指定 Hugo 版本的.tar.gz文件，从中提取 Hugo 二进制文件，并将其放置在bin目录中（删除目录中可能已存在的任何其他 Hugo二进制文件）。现在，我已经修改了install.sh脚本，使其不再下载和提取之前的 Hugo .tar.gz文件，而是获取所需版本的 hvm .tar.gz文件，然后根据需要使用 hvm 来管理 Hugo 二进制文件本身。
这很容易做到，但我的其他 Hugo 管理脚本就完全是另一回事了。由于bin目录在我的$PATH中，这些脚本可以轻松访问 0.153.0 之前的 Hugo 二进制文件，因此可以正常运行各种hugo命令及其标志。然而，hvm 就不同了，它会访问 Hugo 0.153.0 及更高版本的.pkg下载包，并将 Hugo 二进制文件解压到：
/Users/$USERNAME/Library/Caches/hvm/$HUGO_VERSION/hugo
例如，$HUGO_VERSION 是0.153.2 ，这是截至撰写本文时的最新 Hugo 版本。
在这种配置下，我仍然可以毫无问题地从命令行手动运行hugo （无论是否启用特定参数），但脚本却并非如此。具体来说，我使用start.sh进行纯本地开发， testbuild.sh用于生产环境中的本地开发，而build.sh则用于我只想构建网站而不在本地部署的情况。例如， start.sh第3行代码用于按照我的要求运行本地 Hugo 服务器：
hugo server --port 3000 --bind=0.0.0.0 --baseURL=http://${MY_IP}:3000 --panicOnWarning --forceSyncStatic --gc
现在，由于 hvm 安装的 Hugo 二进制文件位于新的位置，该行代码无法“找到” hugo命令——触发了“ Command not found ”的错误响应。关于这个问题，在网上搜索“脚本命令未找到”就能找到大量信息（这篇Red Hat 关于在 Linux 中解决此问题的文章是比较好的参考资料之一，因为 macOS 和 Linux 有很多共同之处）——因此脚本报错。通常的解决方法是将 Hugo 二进制文件的路径硬编码到脚本中；但是，由于路径现在会根据 hvm 使用的 Hugo 版本而变化，我最初以为每次更改 Hugo 版本时都需要对这些脚本进行一些小的修改。
幸运的是，我后来想起 HVM 本身就消除了这种繁琐操作的必要性。
这是因为 hvm 设置过程的一部分涉及对 hvm 在 Hugo 项目根目录下创建的.hvm文本文件进行源代码控制.hvm文件只有一行，列出了你正在使用的 Hugo 版本。例如，我撰写本文时使用的 .hvm 文件只包含以下内容：
0.153.2
这使我的修复工作简化为对每个问题脚本进行一次性修复：
- 添加一个
MY_PATH变量，指向mypath.txt文件的内容，该文件包含 hvm 管理的 Hugo 二进制文件的路径的开头。 - 添加一个指向
.hvm文件内容的HUGO_VERSION变量。 - 将每个 Hugo 命令从
hugo改为${MY_PATH}/hvm/${HUGO_VERSION}/hugo— 然后加上我想要的任何标志（如果有）。
完成这些步骤后，我的脚本就可以像以前一样运行了，让我可以继续按照我喜欢的方式管理我的 Hugo 设置。
这就是我适应这种“新常态”的方式。也许我特立独行，就像我在那期hvm杂志上跟Joe Mooring说的那样；但我提供这些信息，是希望其他使用macOS的Hugo爱好者能在自己的项目中用得上。