Почему "ps aux | grep x" дает лучшие результаты, чем "pgrep x"?

1

Я только что попробовал следующую команду на своем Ubuntu, она ничего не показывает:

pgrep php5

разве он не должен возвращать идентификатор процесса php5 (который просто выполняет следующая команда)?:

ps aux | grep php5

Итак, в чем разница между этими двумя командами?

2

То ps aux | grep x команда дает "лучшие" результаты, чем pgrep x по сути, потому, что вам не хватает опции с последним.

Просто используйте -f вариант для pgrep для поиска по всей командной строке, а не только по имени процесса, которое является его поведением по умолчанию, например:

pgrep -f php5

В отличие от ps | grep конструкция, с помощью которой вам нужно отфильтровать grep линия или используйте приемы с шаблоном, pgrep просто не будет выбирать себя по замыслу.

Более того, если ваш шаблон появится в ps USER столбец, вы получите нежелательные процессы в выходных данных, pgrep не страдает от этого недостатка.

Если вам нужна полная информация, а не только PID, вы можете использовать:

ps wup $(pgrep -f python)

что проще и надежнее, чем

ps aux | grep python | grep -v grep

или

ps aux | grep p[y]thon
3

ps aux включает полную командную строку (путь и параметры), в то время как pgrep просматривает только первые 15 символов имена исполняемого файла

ps aux возвращает полную командную строку каждого процесса, в то время как pgrep просматриваются только имена исполняемых файлов.

Это означает, что греппинг ps aux выходные данные будут соответствовать всему, что встречается в пути или параметрах процесса' binary: например `

  • ps aux | grep php5 будет соответствовать /usr/share/php5/i-am-a-perl-script.pl
  • но pgrep php5 не будет

Возьмем пример из моей системы - только мы будем использовать python вместо php5:

  • ps aux | grep python дает нам:
izx 2348 0.0 0.7 514928 15644 ?        Sl Jun24 0:00 /usr/bin/питон /usr/lib/unity-lens-video/unity-lens-videoizx 2444 0.0 0.9 547392 18864 ?        Sl Jun24 0:01 /usr/bin/питон /usr/lib/unity-scope-video-remote/unity-scope-video-remoteroot 2805 0.0 0.5 95436 12204 ?        S 24 июня 0:00 /usr/bin/питон /usr/lib/system-service/system-service-dizx 6272 0.0 2.9 664400 60320 ?        SNl 24 июня 1:16 /usr/bin/питон /usr/bin/update-manager --no-focus-on-maproot 11729 0.0 0.9 180508 19516 ?        S 25 июня 0:00 питон /usr/lib/программное обеспечение-свойства/программное обеспечение-свойства-dbus
  • Но pgrep python возвращает только 11729, который вы увидите из приведенного выше списка, является:
корень 11729 0,0 0,9 180508 19516 ?        S 25 июня 0:00 питон /usr/lib/программное обеспечение-свойства/программное обеспечение-свойства-dbus
4

<предварительный><код>разница <(ps aux|grep x) <(pgrep x) # :slight_smile:

5

В это время, ps даст более полный результат, чем pgep -f поскольку pgrep ограничен первыми 4096 символами (часто затрагивающими пользователей Java, ищущих класс ввода Java-программы с длинным путем к классу). Отслеживание ошибок это: https://gitlab.com/procps-ng/procps/issues/86

6

Возможно, лучше и быть не может... когда я попытался найти серверный процесс tmux, 

pgrep -l tmux

показал это, но

ps aux | grep tmux

не будет отображаться как сервер, но будет отображаться как команда, которая вызвала запуск сервера. (tmux new -s foo)