极客工场

Appearance

共 2,312 字预计阅读约 8 分钟

Formality 命令不在 PATH：fm_shell command not found 速查 ​

更新时间：2026-10-23。FAQ 速查页，属于 EDA 工具排错系列。新开的终端敲 fm_shell，回一句 command not found——Formality 明明装在工具盘上，但当前 shell 的 PATH 里没有 <install>/bin 这一段。Formality 与 Synopsys 全家桶一样从不进系统默认 PATH，全靠 source <install>/admin/install/setup.csh、module load formality 这类环境注入把它请进来；注入没发生、发生了又没生效、或者生效的是错的版本，表现出来的都是「命令不在」。命令找到了但 license 拉不起来的下一层问题见 Formality license 检出失败，安装路径本身缺失的对照页见 Formality 安装路径不存在。

本文要回答的问题 ​

  • fm_shell: command not found，怎么确认工具装了没、PATH 里有没有？
  • 登录节点能用，cron 和 CI 作业里就找不到，差在哪？
  • module load 报版本找不到，或加载出来的是旧版，怎么纠？
  • setup.csh 在 bash 里 source 报 setenv 错，怎么办？

一、报错原文与现象 ​

bash
bash: fm_shell: command not found
bash: fm: command not found
# 或：环境注入这一步本身就失败
bash: setup.csh: line 8: setenv: command not found
ERROR: Unable to find 'formality/2025.06' in MODULEPATH
# 或：能找到，但版本不对
fm_shell -version  -> 2022.03（预期 2025.06）

先把「不在」分两档：完全找不到——PATH 里压根没有 Formality 的 bin 目录，查环境注入链路；找到的是旧版——PATH 里有 Synopsys 路径，但排在前面那个不是项目要的版本，查 PATH 顺序与多版本共存。两档修法不同，别混在一起调。

二、可能原因总览 ​

报错现象可能原因处置
所有终端都找不到从未 source 环境脚本或加载模块source 组内标准 env 脚本或 module load formality
老窗口正常、新窗口找不到环境只在老窗口手动 source 过写进 shell 启动文件或封装启动脚本
交互能用、cron/CI 里不行非登录非交互 shell 不读 .bashrc/.cshrc作业脚本首行显式 source 环境
module: command not foundmodules 框架本身没初始化source modules 的 init 脚本
module 加载报版本不存在modulefile 版本号写错或已下线module avail 核对后再 load
加载成功但版本是旧的PATH 里旧版 Synopsys 路径排前面purge 清场后按序重载
source setup.csh 报 setenv 错csh 脚本拿到 bash 里执行用 bash 版 setup.sh 或在 csh 里 source
which 有路径但 ls 不存在符号链接失效或工具盘未挂载核对 SYNOPSYS 指向与挂载状态

三、逐条排查展开 ​

第一步：确认三连——装了没、装在哪、PATH 里有没有。

bash
which fm_shell fm 2>/dev/null
echo "$PATH" | tr ':' '\n' | grep -i -e synopsys -e formality
echo "$SYNOPSYS"
ls /tools/synopsys/ 2>/dev/null || ls /opt/synopsys/ 2>/dev/null

先别急着改配置。Formality 的标准安装布局是 <install>/admin/install/ 放安装与环境脚本、<install>/bin/ 放 fm_shell 与 fm 可执行文件，SYNOPSYS 变量指向安装根。如果工具目录本身不存在（这台机器没挂 Synopsys 工具盘），PATH 怎么调都白费——「找不到命令」的根子有时是「文件系统里根本没有这个命令」，这一步确认能省掉后面所有瞎试。

Formality 进 PATH 的标准姿势是注入，不是手改。 正规环境两条通道：environment modules（module avail 看可加载项，module load formality/2025.06 注入指定版本），或厂商/组内维护的 setup 脚本（bash 下 source <install>/admin/install/setup.sh，csh 下 source setup.csh）。setup 脚本会一次设好 SYNOPSYS、PATH、license 变量三件套。在 .bashrc 里手写裸路径是技术债：版本升级时组内模板改一处全员生效，手抄路径的人人的 PATH 都是化石。

新开终端忘了 source，是最常见的人因。 昨天在老窗口手动 source 过环境，今天新开窗口当然找不到——source 只对当前 shell 进程生效，不传染。处置二选一：把加载命令写进 .bashrc（交互登录自动执行），或组内封装一个 fm-run 启动脚本内部先 source 再拉起 fm_shell，所有人统一走入口脚本，不依赖各人记性。

cron 与 CI 作业是另一个世界：非登录、非交互 shell。 交互登录时 shell 读 .bash_profile/.bashrc 完成环境注入；cron 任务和 CI runner 起的 shell 默认不读这些启动文件，你的登录配置一概不执行——这就是「登录节点能用、提交的作业里 command not found」的全部原因。标准做法：作业脚本第一行就是环境加载，与交互环境同源同版本；组内维护一份 env.sh，交互和作业都 source 它，杜绝两环境漂移。临时验证可以 bash -lc 'fm_shell -version' 包一层模拟登录 shell，这样能跑而裸跑不行，就坐实了启动文件没被读取。

csh 脚本拿到 bash 里 source，语法直接不兼容。 Formality 历史环境脚本常以 setup.csh 形式发布，里面是 setenv SYNOPSYS ... 这种 csh 语法；在 bash 里 source 会报 setenv: command not found。bash 的对应写法是 export SYNOPSYS=...。处置：找安装目录下的 bash 版 setup.sh（正规安装通常两个都给）；只有 csh 版本时，要么在 csh/tcsh 里 source，要么把 setenv 逐行翻成 export 维护一份组内 bash 版。

module 系统自身的问题有两层。 第一层：module: command not found——modules 框架本身没初始化，先 source 它的 init 脚本（通常在 /etc/profile.d/modules.sh 或组内指定路径）。第二层：load 报版本不存在——modulefile 的版本串与安装目录真实版本号不一致（版本下线、路径改名或纯粹写错），用 module avail formality 看真实可加载列表照着写。模块文件本身损坏的深层情况见 Formality module 文件加载失败。

容器镜像里的「不在」先问装了没有。 流程迁进容器后，宿主机的模块系统、工具盘挂载、license 变量全部不可见。常见翻车是镜像构建层里验证过（构建脚本 source 过环境），运行时 ENTRYPOINT 没 source，作业一跑就是 command not found。判别口诀：容器里「构建时能跑」不等于「运行时能跑」，两条 shell 是两次环境。

多版本共存时，PATH 顺序决定命运。 重复 module load 不同版本，或 .bashrc 私货在模块注入之后又 prepend 一段旧 Synopsys 路径，which 出来的就是旧版。排查：module list 看当前加载了什么；echo "$PATH" 从头看 Synopsys 路径出现几次、谁先谁后。处置：module purge 清场后按序重载，并清掉 .bashrc 里的私货。版本串台不是小事——Formality 的匹配算法、SVF 引导文件格式按版本对齐，跑错版本会引出一串看似无关的验证失败。

eda/ts-formality-tool-not-in-path.md D2 示意图

颜色按语义分角色：红是报错入口与五类根因，蓝是排查动作，橙是修复，紫是防复发。主线是「先确认三连再分流」：工具盘没挂载是「根本没有」，先解决存在性；装了但 PATH 没有按场景分四支——交互侧 source 标准脚本、cron/CI 作业首行显式加载、csh 脚本换 bash 版、版本串台 purge 重载；所有路径汇到同一个治本动作——交互 shell 与作业脚本共用一份 env.sh。

四、预防与纪律 ​

  • 组内统一 env.sh：Formality 版本、SYNOPSYS、license 变量集中一处，交互 shell 与 cron/CI 作业脚本都 source 它，禁止个人手改 PATH。
  • 作业与 CI 模板首行即环境加载，新任务从模板复制，不从空白写起。
  • 版本切换走模块系统，先 module purge 再 load 目标版本，杜绝叠加污染。
  • bash 环境只 source bash 版脚本；组内维护 csh 到 bash 的对应版本，升级时两份同步更新。
  • 新机器/新账号 checklist：工具盘挂载、modules 初始化、env.sh source、which fm_shell 验证，四步走完才算就绪。
  • 版本基线登记：项目锁定的 Formality 版本写进工程 README，发现串台对照基线纠正。

这一篇在知识体系里的位置 ​

本篇是 EDA 排错速查簇中「运行环境」节点的入口级 FAQ 页，是 Formality 其他排错页的前置条件——命令都起不来，谈不上等价性验证本身的问题。环境通顺后的下一层问题见 Formality license 检出失败 与 Formality module 文件加载失败；安装目录层面的对照页见 Formality 安装路径不存在。

一句话总结 ​

Formality 命令不在 PATH 先做确认三连（装了没、装在哪、PATH 里有没有）再分流：工具盘未挂载解决存在性，装了但 PATH 无则交互侧 source 标准环境脚本、cron/CI 作业首行显式加载、csh 脚本换 bash 版本、版本串台 purge 后按序重载；治本只有一条铁律——交互 shell 与调度作业 source 同一份组内 env.sh，谁手改 PATH 谁还债。