PrimeTime 命令不在 PATH：pt_shell: command not found 速查
更新时间：2026-10-22。FAQ 速查页，属于 EDA 工具排错系列。PrimeTime（简称 PT，Synopsys 的静态时序分析与签收工具，交互壳是
pt_shell）装好了，终端敲下去却只得到一句 command not found——这是换机、换账号、提交批量作业第一天最常见的拦路报错。它几乎从不意味着 PT 没装，而是「当前这个 shell 不知道去哪个目录找它」：PATH 没配、安装根的环境脚本没 source、登录方式不同、LSF 作业丢环境，任一环节错位都会命中。综合侧的同款启动事故见 Design Compiler 命令不在 PATH，机理相通，本篇只讲 PrimeTime 特有的环境脚本、多工具共存与批量作业细节。工具能启动之后的时序问题，同系列见 PrimeTime 时钟/约束缺失。
本文要回答的问题
- 明明装了 PrimeTime，为什么
pt_shell报 command not found？ command -v找不到时，怎么确认 PT 装没装、装在哪个版本目录下？- 安装根下明明有
bin/pt_shell，为什么还必须先 source 环境脚本？ - 交互终端能跑，为什么
bsub、nohup、ssh host pt_shell里就找不到？ - 一台机器同时装了 PT、DC、VCS 多套工具，PATH 冲突怎么理？
一、报错原文与现象
bash 下最典型的形态，连 which 都会把当前 PATH 原样吐出来：
$ pt_shell
-bash: pt_shell: command not found
$ which pt_shell
/usr/bin/which: no pt_shell in (/usr/local/bin:/usr/bin:/bin)zsh 与 tcsh 下措辞不同，含义完全一样，都是 shell 搜遍 PATH 没找到可执行文件：
$ pt_shell
zsh: command not found: pt_shell
% pt_shell
pt_shell: Command not found.第二种形态是「命令找到了却跑不起来」，措辞是 No such file，容易被误判成 PATH 问题：
$ /opt/synopsys/pts/V-2023.12-SP2/bin/pt_shell
-bash: /opt/synopsys/pts/V-2023.12-SP2/bin/pt_shell: No such file or directory文件明明 ls 得到却报 No such file，通常不是路径错，而是二进制与当前机器架构不符（例如把 32 位启动脚本当 64 位跑）或脚本首行指定的解释器不存在——这一类本篇在第三节末尾单独分流。第三种形态来自 module 体系：module: command not found 或 pt_shell: command not found 同时出现，说明连 module 初始化都没做，环境脚本和模块两件事都还没办。
二、可能原因速查表
| 报错/现象 | 最可能原因 | 一条命令确认 | 处置 |
|---|---|---|---|
| which 输出里没有 PT 目录 | PATH 未配置或环境脚本没 source | echo $PATH | source 安装根环境脚本后再 export PATH |
| 配了 PATH 但重开终端失效 | 写错配置文件（bashrc/profile 混淆） | shopt -q login_shell; echo $? | 按登录方式写对文件并重新加载 |
| 交互行、脚本里不行 | 非交互 shell 不读 .bashrc | 脚本里先 echo $PATH 对比 | 脚本首行显式 source 环境 |
| bsub/nohup/ssh 作业找不到 | 作业 shell 是系统最小环境 | 作业日志里打印 PATH | 作业脚本首行 source，不靠转发 |
| 一台机器多版本 PT | PATH 顺序决定先命中谁 | type -a pt_shell | 调整顺序或用 module load 切版本 |
| 与 DC/VCS 目录互相覆盖 | 多套 Synopsys 工具 bin 冲突 | which -a pt_shell dc_shell | 每工具独立 setup 脚本，用时加载 |
| 有绝对路径仍报 No such file | 架构不符或解释器缺失 | file .../bin/pt_shell | 转平台/安装包问题，非 PATH |
| 能启动但报 license 错 | PATH 已通，卡在授权 | echo $SNPSLMD_LICENSE_FILE | 转 license 签出失败篇处理 |
| module 命令本身找不到 | module 初始化未 source | type module | 先 source modules 的 init 脚本 |
三、逐条排查展开
第一步永远是查可见性、查搜索域、查安装位置三件套。
command -v pt_shell
type -a pt_shell 2>/dev/null
echo $PATH
ls -d /opt/synopsys/pts/*/bin 2>/dev/nullcommand -v 是 shell 内建，比 which 更可靠（不依赖外部程序，且对 alias、函数也能识别）；type -a 列出 PATH 中所有同名命中，第一个就是实际执行的那个；ls 安装根回答「PT 到底装没装、装了哪几版」。三个答案摆在一起，问题落在存在性还是可见性立刻分明。PrimeTime 的默认安装形态是 /opt/synopsys/pts/<版本号>/bin/pt_shell，同目录下通常还有 prime_time 启动脚本——两个名字都找不到，才说明 PATH 里确实缺这个 bin 目录。
PrimeTime 与裸 bin 目录之间，通常隔着一层厂商环境脚本。 Synopsys 工具不建议只把 bin 加进 PATH：安装根或管理员集中维护的目录下会有 setup.sh、setup.csh 一类脚本（各站点命名不同，常见 synopsys_setup.sh、setup_pt.csh），它一次设好 PATH、SNPSLMD_LICENSE_FILE（或 LM_LICENSE_FILE）、SNPS 系列变量和动态库路径。正确动作是先 source 它，再敲命令：
source /opt/synopsys/setup_pt.sh
echo $SNPSLMD_LICENSE_FILE
pt_shell -version只把 bin 塞进 PATH 也许能让命令被找到，但 license 变量、库路径缺失会在启动后段连环报错。用 csh/tcsh 的老站点对应动作是 source setup_pt.csh，写进 ~/.cshrc，别把 sh 语法 source 进 csh——那种错法连报错信息都对不上。
配了不生效，九成是 login 与 non-login shell 的配置文件差异。 bash 登录会话（控制台登录、ssh host 直连）读 ~/.bash_profile（或 ~/.profile），终端里再开的交互 shell 读 ~/.bashrc。把 source 写进 .bashrc，登录会话却不读它，是最常见的「昨天还好的今天不行」。稳妥做法是在 .bash_profile 里补一行接力：
[ -f ~/.bashrc ] && source ~/.bashrc改完文件必须 source ~/.bashrc 或重开终端——编辑配置文件不会影响已经在跑的 shell。判断当前是不是登录 shell，用 shopt -q login_shell（返回码 0 是登录 shell）对照即可。
有 module 体系的站点，纪律是用 module load，而不是手改 PATH。
module avail primetime
module load primetime/V-2023.12-SP2
module listmodule avail 看站点装了哪些版本，module list 看当前加载了什么。若 module 本身报 command not found，先 source 模块系统的初始化（如 /usr/share/modules/init/bash，路径问管理员），否则一切 load 都无从谈起。module 的价值在批量环境里加倍：作业脚本里写明加载哪个版本，结果可复现，不依赖提交者当时 export 的是谁。
bsub、nohup、ssh 非登录执行是最严苛的环境，也是 PT 签收作业的主要跑法。 ssh host pt_shell -f run.tcl 走 non-login non-interactive shell，两个配置文件都不读；bsub/qsub 调度作业的 PATH 往往是系统最小集，nohup 脱离终端后同样不继承交互环境的临时 export。判别方法不猜：让失败作业先打印环境再退出，和交互终端一对比，少了什么一目了然：
#!/bin/bash
source /opt/synopsys/setup_pt.sh
module load primetime/V-2023.12-SP2 # 有 module 体系时二选一，别重复
echo "PATH=$PATH"
pt_shell -f signoff.tcl提交侧也可显式转发（bsub -L /bin/bash），但最可靠的永远是作业脚本自包含环境，不假设调度器替你继承什么。
多工具共存时 PATH 顺序决定命中谁。 PT、DC、VCS 各有自己的 bin，若把多个 bin 都前置到 PATH，同名包装脚本、库包装器可能互相遮蔽。用 type -a pt_shell 看全部命中项；正解是每套工具各自一个 setup 脚本，用哪套 source 哪套，版本切换交给 module，禁止在 .bashrc 里堆一串 export 试图「全部都能用」。
最后做一次分流：找到了但跑不起来，不是 PATH 问题。 有绝对路径仍报 No such file，用 file bin/pt_shell 看架构与解释器；启动后报 error while loading shared libraries 是 LD_LIBRARY_PATH 问题；报 Unable to checkout a license、SNPSLMD 连不上，是授权问题，处置见 PrimeTime license 签出失败。第一刀永远切在 command -v 的成败上，三类错别混着治。
读图抓住「红色入口、蓝色排查、橙色修复、绿色收尾」的颜色语义：先证可见性，PATH 里没有 PT 的 bin 才去核实安装；确认装了之后，修复顺序永远是先 source 环境脚本，再解决配置文件放错的登录态问题；交互行而作业不行是独立支线，直接进作业脚本自包含环境。不要跳过 command -v 去重装 PrimeTime，九成是白忙。
四、预防与纪律
- 环境收口到一个脚本：全组统一
setup_pt.sh（安装根、PATH、SNPSLMD_LICENSE_FILE、库路径一次设全），.bashrc与作业脚本都只 source 它，版本升级只改一处。 - 多版本用 module 管理，禁止手工调 PATH 顺序切版本——人脑记不住当前会话 export 的是谁。
- 签收作业脚本必须自包含：bsub、nohup、cron、SSH 远程调用一律首行 source 或 module load，并打印一行 PATH 留痕，不假设任何默认环境。
- 装完即验证：新机器或升级后跑
command -v pt_shell && pt_shell -version，把「装好了」和「当前 shell 能用」分开验证。 - 排查三行口令留给新人：
command -v看可见性、echo $PATH看搜索域、type -a看多版本冲突——八成 command not found 到此结束。
这一篇在知识体系里的位置
本篇是 EDA 排错速查簇中「PrimeTime 工具启动」节点的 FAQ 页，处在签收链路最前端：命令找不到，license、网表读取、时序分析都无从谈起。过了启动这一关，第二道坎是 PrimeTime license 签出失败，多版本共存的后续事故见 PrimeTime 版本不匹配，工具内文件找不到见 PrimeTime 路径/文件不存在；正常启动后的签收方法论见 静态时序分析与 PrimeTime 签收，全簇索引在 开源/EDA 工具报错排查总览。
一句话总结
PrimeTime 报 command not found 时，先用 command -v、echo $PATH、ls 安装根三件套分清是没装还是找不到：装了就 source 安装根的厂商环境脚本（连带 license 与库路径），重开终端失效就查 .bashrc 与 .bash_profile 的登录态接力，bsub、nohup、SSH 作业在脚本首行自包含加载环境，多工具多版本用 type -a 查 PATH 遮蔽并改走 module 管理——九成情况不需要重装任何东西。