ps -ef appname|grep -v grep : How to avoid grep -v grep?"

[Alzhy]

A bud of mine sugegsted a grep syntax that avoids having to do a "grep -v grep in the above construct/usage"

Anyone remember what that construct is?

;^)

[James R. Ferguson · Accepted solution]

Hi Nelson:

# UNIX95= ps -C cron -o pid

...for example to find the 'cron' daemon pid.

To suppress the header, use:

# UNIX95= ps -C cron -o pid=

Note the whitespace after UNIX95= . This keeps the setting only for the duration of the command line --- something that you truly want to do.

Regards!

...JRF...

[Alzhy]

I am not after the PID man..
Am just after a bulet proof way of finding out if process "appname" is running with out the "grep -v grep" as it is thought to waste .00000000000000000018 CPU cycle :^))

It's actually a trivia amongst my team.

[Hein van den Heuvel]

ps -ef | grep [s]omething

Make one of the characters a 'range'

hth,
Hein.

[James R. Ferguson]

Hi (again) Nelson:

> I am not after the PID man..
Am just after a bulet proof way of finding out if process "appname" is running with out the "grep -v grep" as it is thought to waste .00000000000000000018 CPU cycle :^))

That was not the point. The point is that the '-C' switch allows the argument (name) following it to be found based on an exact match to the process basename.

This avoids ambiguous false positive matches and avoids the need to 'grep -v grep'. Of course you could use 'awk' or Perl to pattern match a process basename too.

The '-o' argument(s) allows you to choose what to return --- a pid; the arguments passed (if any) to the process(es); the elapsed time, etc.

Thus, given a process name, the method I showed *is* a very bullet proof way of saying "yes" or "no" to the question of "is a process running". It's not a question of useless processes, forks and CPU cycles.

Regards!

...JRF...

[OldSchool]

Nelson

actually, i think the option you want is on the ps command

UNIX95= ps -fC prngd or
UNIX95= ps -C prngd

will find those processes running the executable with the file base name indicated shown below

UNIX95= ps -C prngd
PID TTY TIME CMD
963 ? 37:20 prngd

the -f will show the full path of the command

[Doug O'Leary]

Hey;

The answer is to put one of the letters of the appname in square brackets:

ps -ef | grep _[p]mon

for example. It's convoluted typing, so I normally end up doing the grep -v grep myself.

Doug

[Bill Hassell]

I've posted this before on the forums:

NEVER use grep with ps.

All the options you need for searching for processes are found in the ps man page. NEVER grep for a PID, use ps -p. Never grep for an owner, use ps -u. Never grep for a process name, use UNIX95=1 ps -C. Note that the -C is not just the basename of the process, it is the actual name found in the process table. It turns out that (hacker code sometimes) can change the name of the process after it starts. The -C option looks in the process table and not the command line string.

grep is not field-sensitive so it looks at every character and it doesn't care about things you don't want matched. grep 123 will also match 11233 and parm131234. Just compare the output of these two commands on your system:

ps -ef | grep sh
UNIX95=1 ps -fC sh

Not only will exactly "sh" be found (rather than unhashdaemon, ksh, bash, etc), but the login shells -sh will also be found. The -w option in grep will find "sh" as a word but treat special chars as a delimiter, still leading to mistakes, especially in command line parameters and strings.

[Dennis Handly]

>JRF: Note the whitespace after UNIX95= .

It is probably much easier to show the following, than to explain about whitespace:
UNIX95=1 ps ...

(Of course you need to say, "No semicolons".)

[James R. Ferguson]

Hi (again):

> Dennis: It is probably much easier to show the following, than to explain about whitespace: UNIX95=1 ps ...

The problem I see with this is that it suggests to the reader that the opposite case (to turn off) might be "UNIX95=0 ps ...".

Unfortunately this is a fallacious assumption. The action 'UNIX95= ' or 'UNIX95=0' or 'UNIX95=1' equally result in an defined value which toggles the XPG behavior. Simply compare:

UNIX95= ps -C sh
UNIX95=0 ps -C sh
UNIX95=1 ps -c sh

Regards!

...JRF...

[Bill Hassell]

> UNIX95...

James is quite right. This variable is part of the XPG4 specifications which defines the existence of the variable as true. So once UNIX95=anything_including_null, the defined behavior is asserted.

Big precaution: Don't export or set UNIX95 in your environments. It can change the behavior of a number of processes and libraries. That's why it is shown assigned on the same line as the process (ie, ps). The definition stays only with the process and disappears when the process terminates. This assignment on the same line as a process is a standard POSIX construct (read: ksh, bash, HP POSIX shell).

[Dennis Handly]

>JRF: The problem I see with this is that it suggests to the reader that the opposite case might be "UNIX95=0 ps ...".

Ok, then use: ;-)
UNIX95=EXTENDED_PS_FEATURES ps ...