Почему «PS Aux | grep x »дает лучшие результаты, чем« pgrep x »?

82

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

pgrep php5

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

ps aux | grep php5

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

command-line bash text

— xczzhh
источник

75

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

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

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

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 / python / usr / lib / unity-lens-video / unity-lens-video
izx 2444 0,0 0,9 547392 18864? Sl Jun24 0:01 / usr / bin / python / usr / lib / unity-scope-video-remote / unity-scope-video-remote
корень 2805 0,0 0,5 95436 12204? S Jun24 0:00 / usr / bin / python / usr / lib / системный сервис / системный сервис-d
izx 6272 0,0 2,9 664400 60320? SNl Jun24 1:16 / usr / bin / python / usr / bin / update-manager --no-focus-on-map
корень 11729 0,0 0,9 180508 19516? S Jun25 0:00 python / usr / lib / software-properties / software-properties-dbus

Но pgrep pythonвозвращается только то 11729, что вы увидите из приведенного выше списка:

корень 11729 0,0 0,9 180508 19516? S Jun25 0:00 python / usr / lib / software-properties / software-properties-dbus

— иш
источник

3

«pgrep -l» также усекает процесс до 15 символов, что, вероятно, является ошибкой, но так было всегда

— Thorsen

1

Ну, это в панели запуска в качестве вышестоящей ошибки с 2008 года :) "команда top и ps truncate после 15 символов" bugs.launchpad.net/ubuntu/+source/procps/+bug/295876

— Торсен

2

Ха, это объясняет это из комментария № 3: Это связано с тем, что некоторые процедуры проков получают имя команды, /proc/<pid>/statа не откуда/proc/<pid>/cmdline . Хорошо, @Thorsen, вы выиграли спрей от ошибок, это ошибка: P

— ish

2

@xczzhh pgrepне является необоснованной командой. Работает хорошо и как задумано. Проблема в том, что вы просто упустили опцию, когда запускаете ее, вы не можете винить pgrepв этом. Использование ps aux | grep xxxненадежно, поэтому нужны хаки, чтобы отфильтровать grepсебя от вывода и может дать ложные срабатывания, как с ps aux | grep root.

— июля 13 июля

1

Это должно быть в антинаркотической рекламе, создатели инструментов bash были настолько взволнованы ЛСД, что думали, что такие вещи были хорошо спроектированы

— Энди Рэй,

78

Команда ps aux | grep xдает «лучшие» результаты, чем, по pgrep xсути, потому что у вас отсутствует опция с последним.

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

pgrep -f php5

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

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

Если вы хотите получить полную информацию, а не только pids, вы можете использовать:

ps wup $(pgrep -f python)

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

ps aux | grep python | grep -v grep

или же

ps aux | grep p[y]thon

— jlliagre
источник

3

Также добавьте опцию -a( --list-full), если вы хотите увидеть полную командную строку, а не только pid. (У старых pgrep не было -a, делал это дальше-fl .)

— Бени Чернявский-Паскин

1

Первоначальный вопрос касался разницы, но на самом деле это дает тем из нас, кто пытается pgrepиграть, хорошее решение. +1

— 2rs2ts

@ 2rs2ts Спасибо, мне действительно не хватало, чтобы ответить на заданный вопрос. Исправлено сейчас.

— Jlliagre

В некоторых случаях, когда программы изменяются, /proc/self/cmdlineчтобы быть «описательными», pgrep -fa rubyне будут совпадать, например. puma 3.3.0 (tcp://localhost:3000) [MIQ: Web Server Worker]пока "тупее" pgrep -a rubyбудет. Не уверен, что последний может быть обманут.

— Бени Чернявский-Паскин

@ BeniCherniavsky-Paskin Я думаю, это могло бы быть комментарием к вопросу, поскольку это относится и к, pgrepи к ps.

— Франклин Ю

3

diff <(ps aux|grep x) <(pgrep x) # :)

— Торсен
источник

12

Это может дать ответ на вопрос - но, возможно, вы можете расширить свой ответ, чтобы объяснить, что делает эта однострочная команда.

— fossfreedom

1

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

— Глина Б.
источник

Искал вечно для этого.

— tresf

Почему «PS Aux | grep x »дает лучшие результаты, чем« pgrep x »?

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

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