Dlaczego „ps aux | grep x ”daje lepsze wyniki niż„ pgrep x ”?

82

Właśnie wypróbowałem następujące polecenie na moim Ubuntu, nic nie pokazuje:

pgrep php5

nie powinien zwracać identyfikatora procesu php5 (co właśnie robi następujące polecenie) ?:

ps aux | grep php5

Jaka jest różnica między tymi dwoma poleceniami?

command-line bash text

— xczzhh
źródło

75

`ps aux`zawiera pełną linię poleceń (ścieżkę i parametry), podczas gdy pgrep sprawdza tylko pierwsze 15 znaków nazw plików wykonywalnych

ps auxzwraca pełny wiersz poleceń każdego procesu, podczas gdy pgreppatrzy tylko na nazwy plików wykonywalnych.

Oznacza to, że dane wyjściowe grepowania ps aux będą pasować do wszystkiego, co pojawi się na ścieżce lub parametrów binarnych procesu: np

ps aux | grep php5 będzie pasować /usr/share/php5/i-am-a-perl-script.pl
ale pgrep php5nie zrobi tego

Weź przykład z mojego systemu - tylko użyjemy Pythona zamiast php5:

ps aux | grep python daje nam:

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
korzeń 2805 0,0 0,5 95436 12204? S Jun24 0:00 / usr / bin / python / usr / lib / system-service / system-service-d
izx 6272 0,0 2,9 664400 60320? SNl Jun24 1:16 / usr / bin / python / usr / bin / update-manager - no-focus-on-map
korzeń 11729 0,0 0,9 180508 19516? S Jun25 0:00 python / usr / lib / software-properties / software-properties-dbus

Ale pgrep pythonzwraca tylko 11729, co zobaczysz z powyższej listy:

korzeń 11729 0,0 0,9 180508 19516? S Jun25 0:00 python / usr / lib / software-properties / software-properties-dbus

— ish
źródło

3

„pgrep -l” również skraca proces do 15 znaków, co jest prawdopodobnie błędem, ale tak było od wieków

— Thorsen

1

No cóż, jest w starterze jako błąd nadrzędny od 2008 roku :) „polecenie top i ps truncate po 15 znakach

— Thorsen

2

Hah, to wyjaśnia, z komentarza nr 3: Wynika to z faktu, że niektóre procedury procs pobierają nazwę polecenia od, /proc/<pid>/statale nie od/proc/<pid>/cmdline . OK, @Thorsen, wygrywasz spray na robaki, to błąd: P

— is

2

@xczzhh pgrepnie jest nierozsądnym poleceniem. Działa dobrze i zgodnie z przeznaczeniem. Problem polega na tym, że po prostu brakowało Ci opcji podczas uruchamiania, nie możesz za to winić pgrep. Korzystanie ps aux | grep xxxjest zawodna, więc trzeba hacki odfiltrować grepsię od wyjścia i może dawać fałszywie dodatnie jak z ps aux | grep root.

— jlliagre

1

Powinno to być w reklamie antynarkotykowej, twórcy narzędzi bash byli tak płonący na LSD, że myśleli, że takie rzeczy są dobrze zaprojektowane

— Andy Ray

78

ps aux | grep xKomenda daje „lepsze” wyniki niż pgrep xw istocie, ponieważ brakuje opcję z nim.

Po prostu użyj -fopcji pgrepdo przeszukania pełnego wiersza poleceń, a nie tylko nazwy procesu, która jest jego domyślnym zachowaniem, np .:

pgrep -f php5

W przeciwieństwie do ps | grepkonstrukcji, w której musisz odfiltrować greplinię lub użyć sztuczek z wzorami, pgreppo prostu nie wybierze się z założenia.

Ponadto, jeśli twój wzór pojawi się w ps USERkolumnie, otrzymasz niechciane procesy na wyjściu, pgrepnie cierpi z powodu tej wady.

Jeśli chcesz uzyskać pełne informacje zamiast samych pid, możesz użyć:

ps wup $(pgrep -f python)

co jest prostsze i bardziej niezawodne niż

ps aux | grep python | grep -v grep

lub

ps aux | grep p[y]thon

— jlliagre
źródło

3

Dodaj także opcję -a( --list-full), jeśli chcesz zobaczyć pełny wiersz poleceń, a nie tylko pid. (Starszy pgrep nie miał -a, zrobił to dalej-fl .)

— Beni Cherniavsky-Paskin

1

Pierwotne pytanie dotyczyło różnicy, ale w rzeczywistości daje to tym z nas, którzy próbują pgrepdobrze grać. +1

— 2rs2ts

@ 2rs2ts Dzięki, rzeczywiście brakowało mi odpowiedzi na zadane pytanie. Naprawiono teraz.

— jlliagre

W niektórych przypadkach, gdy programy zmieniają się /proc/self/cmdlinena „opisowe”, pgrep -fa rubynie będą pasować np. puma 3.3.0 (tcp://localhost:3000) [MIQ: Web Server Worker], podczas gdy „głupszy” pgrep -a rubybędzie. Nie jestem pewien, czy ten drugi też może zostać oszukany.

— Beni Cherniavsky-Paskin

@ BeniCherniavsky-Paskin Wydaje mi się, że mógł to być komentarz do pytania, ponieważ dotyczy zarówno pgrepi ps.

— Franklin Yu,

3

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

— Thorsen
źródło

12

Może to odpowiedzieć na pytanie - ale być może możesz rozszerzyć swoją odpowiedź, aby wyjaśnić, co robi to polecenie w jednym wierszu.

— fossfreedom

1

W tej chwili psda bardziej kompletny wynik niż pgep -fjako, że pgrep jest ograniczony do pierwszych 4096 znaków (często wpływających na użytkowników Java szukających klasy wejściowej programu Java z długą ścieżką klas). Błąd śledzenia to: https://gitlab.com/procps-ng/procps/issues/86

— Glina B.
źródło

Szukałem tego na zawsze.

— tresf

Dlaczego „ps aux | grep x ”daje lepsze wyniki niż„ pgrep x ”?

ps auxzawiera pełną linię poleceń (ścieżkę i parametry), podczas gdy pgrep sprawdza tylko pierwsze 15 znaków nazw plików wykonywalnych

`ps aux`zawiera pełną linię poleceń (ścieżkę i parametry), podczas gdy pgrep sprawdza tylko pierwsze 15 znaków nazw plików wykonywalnych