Question

这是一个测试：

$ bash -c "pgrep -f novalidname"
$ sh -c "pgrep -f novalidname"
11202

为什么pgrep在从sh运行时提供输出？（据我所知，我的计算机上没有名为novalidname）

的进程

Answer 1

这可能是一个时间问题，而pgrep发现自己，因为您发布-f并且novalidname存在于命令行中。尝试使用-l进行确认。

Answer 2

实际解释：

无论标志如何，pgrep 永远不会返回自己的PID。
如果使用简单命令执行bash -c，则bash将exec命令，而不是创建冗余子shell以执行它。因此，bash -c "pgrep -f blah"将使用bash进程替换 pgrep进程。如果pgrep进程是唯一一个命令行包含blah的进程，那么pgrep将不会显示任何PID（按照1）。
dash未执行上述优化。（zsh和ksh会这样做。）因此，如果您的系统sh使用dash实施，那么sh -c "pgrep -f blah"将导致执行两个进程 - sh进程和pgrep子进程 - 两者在命令行中都包含blah。 pgrep不会自行报告，但会报告其父级。

Answer 3

这是一件事（由于延迟而发现自己），另见：

$ ps ax | grep novalidname

这里通常也会显示出来。（在Ubuntu为我做的。（在bash下）

另一件事是/ bin / sh绑定到了什么？

在大多数Linux发行版/ bin / sh上是默认shell的软链接，通常实际上是bash，但可以是任何其他shell。

导致grep / pgrep显示自身的时间差异可能是通过找到一个软链接位置（hm，odd）或某个其他shell绑定到/ bin / sh引入的，它执行与bash略有不同，从而导致延迟流程需要在pgrep中显示。

此外，bash将首先尝试获取〜/ .bashrc并加载其历史记录，而/ bin / sh将执行将要执行的操作。在.bashrc中可以用另一种方式将pgrep定义为别名，这也可能影响差异。

要查看/ bin / sh指向的位置：

$ readlink -e /bin/sh

或者只是跑去看看会出现什么。：d