参考文章：
PATH being overwritten · Issue #6785 · saltstack/salt · GitHub
https://github.com/saltstack/salt/issues/6785
ssh连接远程主机执行脚本的环境变量问题_whitehack的博客-CSDN博客
https://blog.csdn.net/whitehack/article/details/51705889
ssh连接远程主机执行脚本的环境变量问题 (feihu.me)
https://feihu.me/blog/2014/env-problem-when-ssh-executing-command-on-remote/#non-interactive--non-login-shell
发现通过 saltstack 去远程执行脚本因为获取不到 minion 的环境变量导致脚本运行失败
我们先在 master 去获取一下 minion 的环境变量
salt 192.168.149.130 cmd.run 'echo $PATH'
再去 minion 上查看环境变量
是不是发现不对劲了，通过 master 远程获取 minion 的环境变量跟去 minion 本地获取的环境变量不一致！
但在远程主机上操作不也是通过 shell 来执行的吗？难不成在远程主机上操作的 shell 和在本地操作的 shell 有区别？
一般 shell 通常使用的是 bash，所以我们 man 一下看看
BASH 的四种模式
在 man bash 的 INVOCATION一节讲述了 bash 有四种模式
bash 会根据这四种模式而选择加载不同的配置文件，而且加载的顺序也有所不同
里面有两个概念需要先解释一下—— interactive 和 login
login
login 即登录的意思，login shell 是指用户以非图形化界面或者以 ssh 方式登录到机器上时获得的第一个 shell （简单点来说就是需要输入用户名和密码的 shell）
登录机器后用户获得的第一个 shell 就是 login shell
interactive
interactive 即交互式
交互 shell 会有一个输入提示符，并且它的标准输入、输出和错误输出都会显示在控制台上。所以一般来说只要是需要用户交互的，即一个命令一个命令的输入的shell都是 interactive shell
而如果无需用户交互，它便是 non-interactive shell。通常来说如 bash script.sh 此类执行脚本的命令就会启动一个 non-interactive shell，它不需要与用户进行交互，执行完后它便会退出创建的shell
interactive + login shell
第一种模式是 交互式+登录 shell
例如：
用户直接登录到机器上获得的第一个 shell
用户通过 ssh 连接到机器上获得的第一个 shell
加载配置文件：
首先加载 /etc/profile
然后再尝试依次去加载下列三个配置文件之一，找到一个便不再寻找
~/.bash_profile
~/.bash_login
-
~/.profile
non-interactive + login shell
非交互式+登录 shell
例如：
bash -l script.sh
-l 参数是将shell作为一个 login shell 启动，而执行脚本又使它为non-interactive shell
加载配置文件：
首先加载 /etc/profile
然后再尝试依次去加载下列三个配置文件之一，找到一个便不再寻找
~/.bash_profile
~/.bash_login
~/.profile
interactive + non-login shell
交互式+非登录 shell
例如：
在已有的一个 shell 中运行 bash，此时会打开一个交互式的shell，而因为不再需要登陆，因此不是 login shell
加载配置文件：
/etc/bash.bashrc 和 ~/.bashrc
non-interactive + non-login shell
非交互式+非登录 shell
例如：
bash script.sh
ssh user@remote command
这两种都是创建一个shell，执行完脚本之后便退出，不再需要与用户交互
加载配置文件：
会去寻找环境变量 BASH_ENV，将变量的值作为文件名进行查找，如果找到便加载它
总结：
#登录机器后的第一个 shelllogin + interactive#新启动一个 shell 进程，例如运行 bashnon-login + interactive#执行脚本non-login + non-interactive#运行头部有：#!/usr/bin/env bash的可执行文件non-login + non-interactive#通过 ssh 连接到主机login + interactive#远程执行脚本non-login + non-interactive#远程执行命令non-login + interactive#linux 图形化界面non-login + interactive
bashrc VS profile
Linux 是一个多用户的操作系统，每个用户登录系统后，都会有一个专门的运行环境
这个运行环境实际上就是一组环境变量的定义，用户可以对自己的运行环境进行配置，通常在 profile 或者 bashrc 文件下进行修改
bashrc 和 profile 都是 Shell 的启动设置文件(其实这两个文件也是 Shell 脚本)，可以为当前的Shell 初始化环境变量等
profile
某个用户唯一的用来设置全局环境变量的地方
用户登录之后 profile 才会运行
/etc/profile中设定的变量(全局)的可以作用于任何用户
bashrc
bashrc 是在系统启动之后会自动运行
~/.bashrc等中设定的变量(局部)只能继承/etc/profile中的变量，他们是”父子”关系
补充
~/.bash_profile: 每个用户都可使用该文件输入专用于自己使用的 shell 信息，当用户登录时，该文件仅仅执行一次，执行用户的.bashrc文件
~/.bash_logout: 当每次退出系统(退出 bash shell )时，执行该文件
通过上面我们了解到 bash 有四种运行模式
结合上面的问题我们知道：
1. 通过 master 对远程 minion 执行命令是非交互 nologin 模式的bash。获取到的是minion 的 $BASH_ENV 来获取指定配置文件（minion本地设置了这个变量也不行，需要在命令行里设置）
2. 直接在 minion 本地执行命令是交互 login 模式的 bash。获取到的是 minion 的 /etc/profile 文件
3. 因为读取到的配置环境不一样，所以就会出现环境变量不一样的问题
如何解决呢？
方法一
远程执行的命令行里定义一下 $BASH_ENV 路径，让非交互 nologin 模式下的 bash 能够获取到这个变量
salt ip cmd.run 'export BASH_ENV=/etc/profile && 执行命令'或者 source 一下配置文件使其生效，让当前 bash 去获取到环境变量
salt ip cmd.run 'source /etc/profile && 执行命令'方法二
在命令行里加上 runas 参数，加了这个参数之后就相当于会以 runas参数中指定的用户去登录这个 shell，就变成了非交互 login 模式下的 bash
默认会去加载 /etc/profile 配置文件
salt ip cmd.run '执行命令' runas='root'补充：
当 bash 分别用 bash 或者 sh 命令执行时是会有差距的
当 bash 以是 sh 命启动时，即我们此处的情况，bash 会尽可能的模仿 sh（向下兼容），所以配置文件的加载变成了下面这样：
interactive + login: 读取 /etc/profile 和 ~/.profile non-interactive + login: 读取 /etc/profile 和 ~/.profile interactive + non-login: 读取 ENV 环境变量对应的文件 non-interactive + non-login: 不读取任何文件
原文作者：咸鱼运维杂谈；如有侵权，请联系管理员删除。
