ทำไม“ ps aux | grep x” ให้ผลลัพธ์ที่ดีกว่า“ pgrep x” หรือไม่

82

ฉันเพิ่งลองคำสั่งต่อไปนี้บน Ubuntu ของฉันมันไม่แสดงอะไรเลย:

pgrep php5

มันไม่ควรจะส่งคืน ID กระบวนการของ 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 / ระบบบริการ / system-service-d
izx 6272 0.0 2.9 664400 60320? SNl Jun24 1:16 / usr / bin / python / usr / bin / update-manager - ไม่มีโฟกัสบนแผนที่
ราก 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

— ish
แหล่งที่มา

3

"pgrep -l" ตัดทอนกระบวนการให้เหลือ 15 ตัวอักษรซึ่งอาจเป็นจุดบกพร่อง แต่เป็นเช่นนี้มานานแล้ว

— Thorsen

1

มันอยู่ใน launchpad เป็นตัวอัปสตรีม

— Thorsen

2

ฮะนี้จะอธิบายมันจากความคิดเห็น # 3: เพราะนี่คือความจริงที่ว่าขั้นตอนของ procs บางส่วนได้รับชื่อคำสั่งจาก/proc/<pid>/stat/proc/<pid>/cmdlineแต่ไม่ได้มาจาก ตกลง @Thorsen คุณชนะสเปรย์บั๊กมันเป็นข้อผิดพลาด: P

— ish

2

@xczzhh pgrepไม่ใช่คำสั่งที่ไม่สมเหตุสมผล มันทำงานได้ดีและได้รับการออกแบบ ปัญหาคือว่าคุณไม่มีตัวเลือกเมื่อคุณรันคุณไม่สามารถตำหนิpgrepได้ ใช้ps aux | grep xxxเป็นที่ไม่น่าเชื่อถือจึงต้อง hacks จะกรองออกจากตัวเองจากการออกและอาจให้ผลบวกปลอมเช่นเดียวกับgrep ps aux | grep root

— jlliagre

1

ควรจะอยู่ในเชิงพาณิชย์ต่อต้านยาเสพติดผู้สร้างเครื่องมือทุบตีถูกทำให้ตกใจใน LSD พวกเขาคิดว่าสิ่งต่าง ๆ เช่นนี้ได้รับการออกแบบมาเป็นอย่างดี

— Andy Ray

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 .)

— Beni Cherniavsky-ร์กพาสกิน

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จะ ไม่แน่ใจว่าหลังอาจถูกหลอกเกินไป

— Beni Cherniavsky-Paskin

@ BeniCherniavsky-ร์กพาสกินฉันเดาว่าจะได้รับความคิดเห็นที่คำถามเพราะมันนำไปใช้กับทั้งสองและpgrep ps

— Franklin Yu

3

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

— Thorsen
แหล่งที่มา

12

นี่อาจตอบคำตอบของคำถาม - แต่บางทีคุณสามารถขยายคำตอบของคุณเพื่ออธิบายสิ่งที่คำสั่งหนึ่งบรรทัดนี้ทำ

— fossfreedom

1

ในเวลานี้psจะให้ผลลัพธ์ที่สมบูรณ์มากขึ้นกว่าpgep -fที่ pgrep จะถูก จำกัด ที่ 4,096 ตัวอักษรแรก (มักจะส่งผลกระทบต่อผู้ใช้ Java ที่กำลังมองหารายการระดับของโปรแกรม Java ที่มี classpath ยาว) ข้อผิดพลาดในการติดตามคือ: https://gitlab.com/procps-ng/procps/issues/86

— ดิน B
แหล่งที่มา

มองหาสิ่งนี้ตลอดไป

— tresf