10

I'm a newbie to shell programming. Assuming that I've started a program(eg NetBeans) from my terminal, if I type

ps aux|grep netbeans

I get the the output 

pre      18775  1.2  0.0  12524  1972 pts/3    S    20:17   0:00

where 18775 specifies the PID etc of the process.

Then I kill it using

kill 18775.

upon which the NetBeans UI disappears. If I try to get the pid by using the first command, I still get:

pre      19137  0.0  0.0   9136  1068 pts/3    S+   20:19   0:00 grep --color=auto netbeans

If the process has been killed, why does it still show the above output?

Improve this question
1
  • 2
    It's not showing you the netbeans process - it's showing the grep process through which ps aux is being piped! Since that process is grep netbeans, that's the program you see at the end of the line (grep --color=auto netbeans)
    – David Puglielli
    Nov 17, 2011 at 15:02

3 Answers 3

Reset to default
17

grep is grepping itself. Try something like:

ps aux |grep [n]etbeans

this keeps grep from showing itself in the output

Improve this answer
2
  • 2
    This works, but it is not very nice. You could also do ps aux | grep netbeans | grep -v grep. But use pgrep instead.
    – Martin Ueding
    Nov 17, 2011 at 15:11
  • 1
    @queueoverflow pgrep would be nice, but it only matches the process name. The first pattern can match any column of ps. (For example, something running under python or java, pgrep wouldn't be grepping the correct thing. Same with pkill and so on..)
    – Izkata
    Nov 17, 2011 at 19:06
5

Never use ps together with grep.

Rather, use killall netbeans, pkill netbeans to kill it. For the process ID pgrep netbeans.

More on ps and grep.

Improve this answer
4
  • 11
    That's the most useless advice I've ever heard. As long as people know what the grep process will look like in the output of ps (it starts with "grep") then there is absolutely no danger in using the two together. I do understand the advice about not using a kill in a script, but that's beside the point.
    – ovangle
    Nov 17, 2011 at 15:25
  • 3
    And I think pgrep is worse, because it's just begging you to 'kill $(pgrep vi*)' or something amazingly unsafe like that.
    – ovangle
    Nov 17, 2011 at 15:36
  • 1
    This is also the most useless answer on this page, as pgrep, pkill, and so on match process name only - anything being interpreted (java, python, bash, etc...) can only be distinguished from others under the same process name by using ps.
    – Izkata
    Nov 17, 2011 at 20:57
  • 3
    @Izkata - using -f for pgrep and pkill will match against the entire command line. It's sometimes useful when trying to match stuff run under interpreters as you mention. It's also a good way to shoot yourself in the foot as it will happily kill anything that references your pattern anywhere in its command line :)
    – roadmr
    Nov 18, 2011 at 21:45
4

Because that's the PID for the grep process which is queued up to run after ps aux.

Improve this answer
2
  • @ovangle- blink I never thought of it! :D thanks!
    – P Ramesh
    Nov 17, 2011 at 15:04
  • 1
    Actually, grep is already running when ps aux runs. As ps aux runs, its output is sent to the running grep instance as input. If the shell hadn't executed grep yet, it wouldn't appear in the output of ps.
    – Eliah Kagan
    Mar 3, 2013 at 3:28

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .