Stack Exchange Network

Stack Exchange network consists of 183 Q&A communities including Stack Overflow , the largest, most trusted online community for developers to learn, share their knowledge, and build their careers. Visit Stack Exchange

Ask Ubuntu is a question and answer site for Ubuntu users and developers. It only takes a minute to sign up.

Sign up to join this community

Teams

Q&A for work

Connect and share knowledge within a single location that is structured and easy to search.

Learn more about Teams

pgrep php5
shouldn't it return the process ID of php5 (which the following command just does)?:
ps aux | grep php5
So, what's the difference between these two commands?
The ps aux | grep x command gives "better" results than pgrep x essentially because you are missing an option with the latter.
Simply use the -f option for pgrep to search the full command line and not only the process name which is its default behavior, eg:
pgrep -f php5
Unlike the ps | grep construction with which you need to filter out the grep line or use pattern tricks, pgrep just won't pick itself by design.
Moreover, should your pattern appear in ps USER column, you'll get unwanted processes in the output, pgrep doesn't suffer from this flaw.
If you want full details instead of just the pids, you can use:
ps wup $(pgrep -f python)
which is simpler and more reliable than
ps aux | grep python | grep -v grep
ps aux | grep p[y]thon
                Also add the -a (--list-full) option if you want to see the full command line and not just the pid.  (Older pgrep had no -a, did this on -fl.)
– Beni Cherniavsky-Paskin
                Aug 12, 2014 at 8:51
                The original question was asking about the difference but this actually gives those of us trying to get pgrep to play nice the solution. +1
– 2rs2ts
                Jun 25, 2015 at 21:32
                In some cases when programs modify /proc/self/cmdline to be "descriptive", pgrep -fa ruby will not match eg. puma 3.3.0 (tcp://localhost:3000) [MIQ: Web Server Worker], while the "dumber" pgrep -a ruby will.  Not sure if the latter may be fooled too.
– Beni Cherniavsky-Paskin
                May 1, 2016 at 12:47
                @BeniCherniavsky-Paskin I guess that could have been a comment to the question, since it apply to both pgrep and ps.
– Franklin Yu
                Jul 7, 2016 at 6:13
ps aux includes the full command line (path and parameters), while pgrep only looks at the first 15 characters of the executable's names
ps aux returns the full command line of each process, while pgrep only looks at the names of the executables.
That means that grepping ps aux output will match anything that occurs in the path or the parameters of a process' binary: e.g. `
ps aux | grep php5 will match /usr/share/php5/i-am-a-perl-script.pl
but pgrep php5 won't
Take an example from my system -- only we'll use python instead of php5:
ps aux | grep python gives us:
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
root      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
root     11729  0.0  0.9 180508 19516 ?        S    Jun25   0:00 python /usr/lib/software-properties/software-properties-dbus
But pgrep python returns only 11729, which you'll see from the above list is:
root     11729  0.0  0.9 180508 19516 ?        S    Jun25   0:00 python /usr/lib/software-properties/software-properties-dbus
                "pgrep -l" also truncates the process to 15 characters, which is probably a bug but has been like this for ages
– Thorsen
                Jun 28, 2012 at 10:23
                Well it's in launchpad as an upstream bug as of 2008 :) "top and ps truncate command after 15 chars" bugs.launchpad.net/ubuntu/+source/procps/+bug/295876
– Thorsen
                Jun 28, 2012 at 10:42
                Hah, this explains it, from comment #3: This is due to the fact that some procedures of procs get the command name from /proc/<pid>/stat but not from /proc/<pid>/cmdline. OK, @Thorsen, you win the bug spray, it's a bug :P
– ish
                Jun 28, 2012 at 10:57
                Thank you so much. According to your answer, pgrep is quite an unreasonable command, because it could well ignore all the running process in some circumstances(e.g.,my php5). Is there any other convincible reason that this command should exist?
– xczzhh
                Jun 28, 2012 at 13:22
                @xczzhh pgrep is not an unreasonable command. It works well and as designed. The issue is simply you were missing an option when you run it, you can't blame pgrep for that. Using ps aux | grep xxx is unreliable so need hacks to filter out grep itself from the output and might give false positives like with ps aux | grep root.
– jlliagre
                Aug 1, 2013 at 22:23
                This may answer the answer the question - but perhaps you can expand your answer to explain what this one line command does.
– fossfreedom
                Jun 28, 2012 at 18:46