这个坑我之前踩过好几次，核心原因是bash在非交互式非登录模式下的启动规则，以及多数系统默认的~/.bashrc里会有一个“非交互式就退出”的判断逻辑，导致你的PATH设置根本没机会执行。

先搞懂为什么source没用 #

你可以先远程执行这条命令验证一下：

ssh <host> 'source ~/.bashrc; echo $-'

输出里大概率没有i这个字符——i代表交互式shell。而几乎所有默认的~/.bashrc开头都会有类似这样的代码：

# 如果不是交互式shell，直接退出
case $- in
    *i*) ;;
      *) return;;
esac

或者更简洁的：

[ -z "$PS1" ] && return

当你用ssh <host> <command>执行命令时，bash是以非交互式shell启动的，所以上面的判断会触发return，~/.bashrc里后面的PATH设置完全不会被执行，哪怕你手动source也没用！

解决方案1：调整~/.bashrc的结构（推荐） #

把你的PATH定义移到那个“非交互式判断”的前面，这样不管bash是不是交互式，都会加载PATH配置。修改后的~/.bashrc大概是这样：

# 先设置全局需要的环境变量，比如PATH
export PATH="/path/to/your/app1:/path/to/your/app2:$PATH"

# 下面是仅针对交互式shell的配置
case $- in
    *i*) ;;
      *) return;;
esac

# 这里放提示符、别名、交互式专属的配置
export PS1="\u@\h:\w\$ "
alias ll='ls -alF'

这样之后，不管你是ssh登录交互式shell，还是远程执行命令，PATH都会生效。

解决方案2：强制使用登录shell执行命令 #

如果你不想修改~/.bashrc，可以用bash -l强制启动登录shell——登录shell会自动加载_{/.bash_profile（如果存在），而多数系统的}/.bash_profile里会有source ~/.bashrc的逻辑。执行命令的格式如下：

# 注意转义$PATH，避免本地shell先解析它
ssh <host> "bash -l -c 'echo \$PATH'"
# 或者用单引号嵌套的写法
ssh <host> 'bash -l -c '\''echo $PATH'\'''

这样登录shell会完整加载你的环境配置，PATH自然就对了。

解决方案3：指定bash加载~/.bashrc #

bash提供了--rcfile参数，可以强制指定加载的配置文件，绕过非交互式的判断限制。用法如下：

ssh <host> "bash --rcfile ~/.bashrc -c 'echo \$PATH'"

这种方式适合临时测试，不需要修改远程的配置文件。

内容的提问来源于stack exchange，提问作者Jason Lee