我在这里读过几篇关于pgrep“似乎”返回自身的文章，尽管它永远不应该返回。关键似乎是bash和sh的功能之间的区别。除此之外，我已经确认sh确实是bash的链接。
我在SuSE 12 x86_64上运行
/bin/sh是指向bash的链接
/bin/bash是真正的二进制文件
我有一个Ruby脚本，它调用pgrep如下：
cmd="/usr/bin/pgrep -lf \"#{target}\""
pidList=`#{cmd}`
我需要使用完整的命令行，因为我实际上使用了一个参数来唯一地标识一个特定的“java”进程。
现在，由于一些不相关的愚蠢，我几乎立即对返回的每个pids执行
ps -p操作。有一段时间，这让我非常悲伤，因为ps有时什么也不回。最后，我发现了一个情况，即pid上的ps返回了pgrep命令。但这是pgrep命令本身，而不是sh -c "pgrep -f blah"总结一下：
pgrep从不返回自身。但是sh和bash之间的差异会导致它显示一个子shell。但是我验证了sh是指向bash的链接，所以行为上应该没有区别。
我怀疑（并且正在寻找确认）是因为Ruby backticks而创建了一个额外的子命令，这就是（只是有时。。时间问题？）被pgrep命令接收。
这是一个真正的痛苦，我想确保我实现的修复将真正使问题消失。考虑到我使用的代码，我要么
在我的命令末尾附加一个
| grep -v grep在Ruby脚本中循环返回的结果时抛出任何包含“grep”的结果
我觉得#2更快，但它仍然让我恼火，我必须过滤掉pgrep本身。
我是在正确的轨道上，还是你认为还有别的事情在起作用？
谢谢你的时间！
最佳答案
问题不在于shell风格：调用pgrep的shell进程也显示在进程之间（并且在其完整命令中包含搜索字符串），因此我们需要这样过滤它：
pgrep -f target | grep -v $$
关于ruby - 关于pgrep返回自身的确认，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/41816962/