ARTICLE DETAIL

资讯详情

深耕网站视觉设计与运营推广的一线实战洞察。

TIL:AWS CLI 报错 “Could not find executable named ‘groff‘“ 的根因与两种修复方案

TIL:AWS CLI 报错 “Could not find executable named ‘groff‘“ 的根因与两种修复方案 文档教程知识库【免费下载链接】til:memo: Today I Learned项目地址https://gitcode.com/gh_mirrors/ti/til点击查看免费下载在 macOS 上使用 AWS CLI 查看命令帮助例如aws logs tail help时有时会突然报出Could not find executable named groff。这篇笔记记录了这个错误的成因——macOS Ventura 用mandoc取代了groff导致旧版 AWS CLI 的帮助渲染链路失效——并给出两种行之有效的修复路径补装groff或把 AWS CLI 升级到内置mandoc回退逻辑的新版本。读完本文你将能快速定位该报错、按自己的安装方式选择修复手段并完成验证。问题现象help 命令直接失败作者在已安装 AWS CLI 的机器上执行某些命令时例如aws logs tail my_log_group甚至仅仅是查看帮助aws logs tail help都会得到如下报错$ aws logs tail help Could not find executable named groff注意报错并不只在真实业务命令上出现连help子命令本身也会触发。这说明问题不是出在 CloudWatch Logs 的服务端而是 AWS CLI 的本地帮助渲染流程依赖了系统里缺失的某个可执行文件。从仓库中另一篇相关笔记 aws/find-and-follow-server-logs.md 可以看到aws logs tail help正是排查日志类命令时的第一步——先通过 help 了解参数再执行aws logs describe-log-groups查找日志组最后用aws logs tail group --follow跟进日志。因此这条 help 链路被中断会直接拖慢日常排障节奏。根因macOS Ventura 用 mandoc 取代了 groffAWS CLI 的帮助命令在渲染 man 风格帮助页时需要调用groff这个 GNU 排版工具。而 macOS Ventura 的系统更新把原本随系统分发的groff替换成了mandoc导致groff不再存在于 PATH 中AWS CLI 随即抛出上述报错。这一现象主要影响 macOS Ventura 上的旧版本 AWS CLI。AWS CLI 官方仓库的 pull request #7413 对这一问题做了明确说明The CLIs help commands are currently broken on macOS Ventura because Ventura has replaced groff with mandoc. This PR fixes the issue by falling back on mandoc if groff doesnt exist in the path.即在 Ventura 上groff被mandoc替代CLI 的帮助命令因此失效该 PR 的修复思路是在 PATH 中找不到groff时自动回退到mandoc。也就是说这本质上是旧版 CLI 对环境变化的适配问题而不是 AWS 服务端的故障。方案一补装缺失的 groff 依赖最直接的办法是把缺失的groff可执行文件装回来。在 macOS 上使用 Homebrew 安装brew install groff安装完成后之前失败的aws logs tail help即可正常渲染帮助页。这种方式相当于补齐环境缺口不改变 AWS CLI 本身的版本适合不想动 CLI 版本、或暂时无法升级的场景。需要提醒的是brew install groff是一次常规的 Homebrew 安装操作。仓库笔记 unix/fix-shim-path-after-asdf-upgrade.md 记录过一个真实教训执行brew install groff时Homebrew 可能顺带升级机器上的其它包如asdf进而引发工具链路径变化例如 asdf 的 shims 路径配置失效、.zshrc中旧的 source 路径报错。因此安装后如果发现其它命令行工具行为异常可以顺带检查一下 Homebrew 是否连带升级了相关工具。方案二升级 AWS CLI 到带回退逻辑的版本另一种思路是从源头解决把 AWS CLI 升级到包含groff缺失时回退到mandoc逻辑的版本即合并了上述 PR 的版本。升级后即使系统仍没有groffCLI 也能借助mandoc正常展示帮助页。具体的升级命令取决于当初的安装方式如果使用的是官方安装脚本通过官方安装/升级指引安装的二进制版本按官方升级步骤重新获取最新版本即可如果是通过pip安装的升级命令为pip install --upgrade awscli如果是通过 Homebrew 安装的升级命令为brew upgrade awscli升级完成后可以通过aws --version确认版本号再重新运行aws logs tail help验证帮助页是否恢复正常。两种方案如何取舍方案适用场景关键命令补装 groff不想变更 CLI 版本、需要快速恢复帮助功能brew install groff升级 AWS CLI希望一劳永逸适配 Ventura、顺手获得新版功能与修复官方安装脚本 /pip install --upgrade awscli/brew upgrade awscli从长期角度看升级 CLI 是更根本的解法新版 CLI 在缺少groff时会自动回退到mandoc不再依赖补齐系统组件。而补装groff则适合临时应急或处于版本锁定约束下的环境。延伸help 之外的相关 CLI 行为这个报错发生在 AWS CLI 渲染帮助文本的环节与之相邻的还有 AWS CLI 的 pager 行为。仓库笔记 aws/turn-off-output-pager-for-a-command.md 提到CLI 大量输出默认会送入less之类的 pager在排查日志、枚举资源等场景中可以按需使用--no-cli-pager让结果直接输出到 stdout或通过aws configure set cli_pager 全局关闭。理解 help 渲染与 pager 这两条输出链路能帮助你在 macOS 上更顺畅地使用 AWS CLI 的日常排障命令。小结Could not find executable named groff是 macOS Ventura 系统组件变更groff→mandoc与旧版 AWS CLI 之间的兼容性问题。修复方式二选一要么brew install groff补齐依赖要么升级 AWS CLI 到支持mandoc回退的新版本pip install --upgrade awscli或brew upgrade awscli。验证时只需重新执行之前报错的aws logs tail help即可。这条经验收录于本仓库的 AWS 分类笔记与 find-and-follow-server-logs.md、turn-off-output-pager-for-a-command.md 等笔记相互印证共同构成 macOS 上使用 AWS CLI 的实用排障手册。赞分享文档教程知识库【免费下载链接】til:memo: Today I Learned项目地址https://gitcode.com/gh_mirrors/ti/til点击查看免费下载相关推荐Lingo.dev CLI 打包报错 Dynamic require of ... is not supported 的根因与修复tsup external 配置实战Lingo.dev CLI 打包报错 Dynamic require of ... is not supported 的根因与修复tsup externa开发工具AI 应用前端解决 Fastlane 安装噩梦Could not find nkf 错误的终极方案解决 Fastlane 安装噩梦Could not find nkf 错误的终极方案 你是否在部署 iOS/Android 自动化流程时被 Coul开发工具CI/CD移动开发编译 MNN 转换器报 “Could NOT find Protobuf” 怎么解决编译 MNN 转换器报 “Could NOT find Protobuf” 怎么解决 编译 MNN 模型转换器 DMNN_BUILD_CONVERTERO人工智能大模型推理引擎深度学习本地部署模型量化模型优化多模态计算机视觉嵌入式创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考
返回列表