Docker非交互运行时无法识别.pyenv shims下的可执行程序

该问题本质是pyenv shims的路径加载规则和Docker不同启动模式下的Shell初始化逻辑差异共同导致的：

• pyenv默认不会自动把shims目录加入系统全局PATH，Gitpod的基础镜像将/home/gitpod/.pyenv/shims加入PATH的配置，写在gitpod用户家目录下的.bashrc、.profile等用户级Shell初始化脚本中。
• 当你用交互模式进入容器（即手动执行/bin/bash进入交互式命令行）时，启动的是交互式登录Shell，Bash会自动加载上述用户级初始化脚本，PATH中包含pyenv shims路径，因此可以正常识别jupyter等shims目录下的命令。
• 当你通过docker run直接传命令、或者通过Dockerfile的CMD/ENTRYPOINT指令执行命令时，启动的是非交互非登录Shell，这种模式下Bash不会加载用户家目录下的初始化脚本，PATH中没有pyenv shims的路径，自然无法找到对应命令，触发command not found报错。
• 你能通过ls /home/gitpod/.pyenv/shims列出目录下的文件，是因为命令中直接写了shims目录的绝对路径，不依赖PATH检索，和环境变量是否加载无关。

你可以根据使用场景选择以下任意一种方案：

方案1：启动命令时主动加载Shell配置 #

执行命令前让Bash以登录Shell模式启动，同时加载用户初始化脚本，即可拿到包含pyenv shims的PATH配置：

• 直接docker run执行命令时，使用如下写法：

docker run -it --rm gitpod/workspace-full /bin/bash -lc "source ~/.bashrc && jupyter --version"

• Dockerfile中配置CMD时对应修改为：

FROM gitpod/workspace-full
CMD ["/bin/bash", "-lc", "source ~/.bashrc && jupyter --version"]

参数-l的作用是让Bash以登录Shell模式运行，会自动加载用户级profile配置，搭配source ~/.bashrc可以确保所有路径配置完整加载。

方案2：镜像层面全局配置PATH（推荐，最稳定） #

直接在Dockerfile中通过ENV指令将pyenv相关路径写入全局环境变量，完全绕开Shell初始化脚本的加载差异，无论哪种模式启动容器都能正常识别命令：

FROM gitpod/workspace-full
ENV PYENV_ROOT="/home/gitpod/.pyenv"
ENV PATH="$PYENV_ROOT/shims:$PYENV_ROOT/bin:$PATH"
CMD ["jupyter", "--version"]

这种方案不依赖任何Shell启动时的脚本加载逻辑，适配容器非交互运行、定时任务、集群调度等所有场景，稳定性最高。

方案3：直接调用可执行文件的绝对路径 #

你也可以跳过PATH检索，直接写pyenv安装的可执行文件的完整路径执行，但是这种方式依赖pyenv安装的具体Python版本，版本变更后路径需要同步修改，灵活性差，不推荐常规使用：

docker run -it --rm gitpod/workspace-full /home/gitpod/.pyenv/versions/3.8.13/bin/jupyter --version

内容的提问来源于stack exchange，提问作者Artem Sokolov