标签：
首先，我们想到的会是 export（等价于 declare -x）命令：
|
$ export | grep ‘declare -x _=‘ |
没有找到，那么结论就是 _ 不是环境变量？当然没那么简单，否则本篇文章就该结束了。别忘了还有 env（或者 printenv）命令：
|
$ env | grep ‘_=‘ _=/usr/bin/env |
这下怎么办，_ 到底是不是环境变量？谁说的对？然而下面还有更诡异的：
|
$ bash -c "export | grep ‘declare -x _=‘" declare -x _="/bin/bash" $ bash -c ":;export | grep ‘declare -x _=‘" |
当用 bash -c 的方式执行且 export 是第一条命令的时候，_ 被认为是环境变量，一旦执行过别的命令，_ 就变成了非环境变量。
为了找到答案，我只好去翻阅 Bash 源码，下面直接说出我从源码中得出的三点结论：
当 Bash 启动时，如果 Bash 的父进程的环境变量里有 _，那么 Bash 一定也会继承这个环境变量，这是操作系统层面的实现，Bash 也不可能违背。如果父进程没有 _ 环境变量，那么 Bash 会自己创建 _ 这个环境变量，并把它的初始值赋值为 $0，相关代码在 variables.c 里的 initialize_shell_variables 函数里：
/* Set up initial value of $_ */
temp_var = set_if_not ("_", dollar_vars[0]) # 如果用 Bash 代码翻译这句 c 代码就是：[[ -z $_ ]] && export _=$0
_ 变量的值就是最后一条命令的最后一个参数，所以显然在执行完任意一条命令之后，Bash 都得为这个变量重新赋值，不过除了赋值之外，Bash 还做了一件事，就是把 _ 变量标记为非环境变量。在 execute_cmd.c 里有个 bind_lastarg 函数就是来干这两件事的：
static void
bind_lastarg (arg)
char *arg;
{
SHELL_VAR *var;if (arg == 0)
arg = "";
var = bind_variable ("_", arg, 0); # 这句代码是把 _ 的值设置成上次命令的最后一个参数
VUNSETATTR (var, att_exported); # 这句是把 _ 标记为非环境变量
}
在执行外部命令之前，Bash 会专门把 _ 的值设置成这个外部命令的路径，同时把 _ 标记为环境变量。相关代码在 execute_cmd.c 里的 execute_disk_command 函数中：
put_command_name_into_env (command);
这个 put_command_name_into_env 函数的实现在 variables.c 里：
void
put_command_name_into_env (command_name)
char *command_name;
{
update_export_env_inplace ("_=", 2, command_name); # 这句代码翻译成 Bash 代码就是：export _=$command，command 就是外部命令的路径
}
三点结论说完了，然后再回头看看刚才那些看似诡异的代码示例。
因为我们执行测试代码通常是在交互式的 Shell 下进行的，交互 Shell 会执行 .bashrc 启动脚本，所以当我们执行 export 命令的时候，一定已经执行过别的命令了，在执行任意命令之后，Bash 都会把 _ 标记为非环境变量，所以 export 看不到 _，我们可以开启一个不执行 rc 脚本的交互 Shell 再看看：
|
$ bash --norc $ export | grep ‘declare -x _=‘ # bash 也是个外部命令，所以按照上面第 3 点结论里说的，现在这个 Shell 的父 Shell 会把 _ 标记为环境变量， # 同时把它的值设置为 bash 的路径，现在这个 Shell 继承了 _ 这个环境变量，所以这里能看到 _ declare -x _="/bin/bash" $ export | grep ‘declare -x _=‘ # 当执行完前一条命令后，按照上面第 2 点结论里说的，当前 Shell 会把 _ 标记为非环境变量，所以这里 _ 已经不是环境变量了 |
env 一直能看到，是因为 env 是外部命令，在执行它之前 Bash 总会把 _ 标记为环境变量，同时把 _ 的值设置为 /usr/bin/env。
虽然 export _ 会把 _ 标记为环境变量，但因为 export _ 也是一条命令，按照上面第二点结论说的，当 export _ 执行结束后，Bash 又把 _ 标记成了非环境变量。
证明一下 Bash 会继承父进程的 _ 环境变量，以及在父进程没有 _ 环境变量的时候 Bash 也会在启动时建立这个环境变量。
|
$ env bash -c ‘echo $_‘ # env 继承了当前 Shell 专门为它设置的 _ 环境变量，然后又传给了它的子进程 Shell /usr/bin/env $ env _=1 bash -c ‘echo $_‘ # env 重新赋值了 _，然后又传给了 bash 1 $ python # 在 Bash 里没法删除 _ 变量，env 命令也只能改值而不能删除，所以这里用 Python 演示 >>> import os |
看一下 manual 里讲 $_ 的段落省略了哪些信息：
At shell startup, set to the absolute pathname used to invoke the shell or shell script being executed as passed in the environment or argument list
这里说的只是如果没有从父进程继承到 _ 时的表现，如果继承到了 _，不会做这件事。
Subsequently, expands to the last argument to the previous command, after expansion.
没有说同时会把 _ 标记为非环境变量。
Also set to the full pathname used to invoke each command executed and placed in the environment exported to that command.
没说清楚，这里的 command 只指外部命令。
总结一下，这个问题的答案就是：_ 在 Bash 刚刚启动的时候（执行第一条命令之前）或者在执行外部命令之前的那一刻是环境变量，在其他时候都是非环境变量。
标签：
原文地址：http://www.cnblogs.com/ziyunfei/p/4787089.html
