grep command acts stupid

[Shantaram Sahyadri]

Hi,
does any one have any idea why grep fails to honour any options assigned to it, say like

ps -eaf | grep -i armserver | grep -v grep

should display all lines matching with armserver but not catch grep itself, but the command fails sating -v is unknow option. similarly I have probems when I specific mutiple strings using -e option.

can any one tell me why some commands act so strange.

[Duncan Edmonstone]

Which grep are you using - check its the usual one in /usr/bin by issuing the following command:

which grep

Also check you don't have an alias set for it by listing all your aliases:

alias


HTH

Duncan

[Hein van den Heuvel]

Right, check which grep is being used and/or an alias perhpas.

As for the original problem, searching for a ps line without finding the searcher, I like to use a very simple regular expression instead of the target string.
For example grep for "armserve[r]" instead of armserver. This will no long match the grep command itself.

Hein.

[Shantaram Sahyadri]

Hi,
Thanks for your reply,

I am using /usr/bin/grep itself, and problem seems to occur when it is been called from within a script.
I alos tried using the UNIX95 option, still it does sometimes does the same act.

[Peter Godron]

Hi,
if the problem only occures inside the script, try the which grep within the script, as you may be changing PATH.
Regards

[Shantaram Sahyadri]

Hi,
inside the scrip has variabe defined for grep like

GREP=/usr/bin/grep

so there is issue of PATH settings.

[Shantaram Sahyadri]

hey there is some typing error in my last message.

In side the script I have a variable defined for all tools used
like

GREP=/usr/bin/grep
AWK=/usr/bin/awk

so when executing the script there is not path problems to encounterd.

regards

[harry d brown jr]

do a
what `which grep`
and a
what /usr/bin/grep

example:
[root@vpart3 /opt/appl]# what `which grep`
/usr/bin/grep:
$Revision: B.11.11_LR
Fri Oct 27 00:57:38 PDT 2000 $
[root@vpart3 /opt/appl]#


Is this by chance a 10.20 or less HP-ux??

Or is this a sun box??

Does the error look like this when you use the "-e" option?

[root@pbsbcp /]# ps -ef | grep -e root
grep: illegal option -- e
Usage: grep -hblcnsviw pattern file . . .
[root@pbsbcp /]#


live free or die
harry d brown jr

[Shantaram Sahyadri]

Hi,

Thanks harry for u reply,

this is a HP 9000/800/L2000 running 11i v1 with Gold Base June 2004 and another with Dec 2004 patch. yes the probem occurs usally when used with -e switch.

well I have the same script dito working in some other 11i boxes as well was linux and sun boxes. it works fine every where.

[harry d brown jr]

And what does


what `which grep`
and
what /usr/bin/grep

return??


live free or die
harry d brown jr

[Elmar P. Kolkman]

Or do 'set -x' before and 'set +x' after the failing commandline to make sure what happens. This will print (a lot of) debugging info on what goes on in a commandline...

[Rodney Hills]

Since you say you are doing-
GREP=/usr/bin/grep

does that mean in your script you are doing-
ps -eaf | $GREP -i armserver | $GREP -v grep

If you are not, then the GREP= line isn't doing anything. If you are assuming it identfies where the command is, you are mistaken. The variable "PATH" defines where commands are looked for.

-- Rod Hills

[Shantaram Sahyadri]

Hi
Thanks for all your help,

yes the script goes like

GREP=/usr/bin/grep

ps -eaf | $GREP -i armserver | $GREP -v grep

regards

[Michael Schulte zur Sur]

Hi,

-e expects a pattern and has to come after -v. Do you use it that way?

greetings,

Michael

[Shantaram Sahyadri]

Hi,

here is the line as it is in the script


GREP=/usr/bin/grep
set -x
ps -eaf | $GREP -i -e armserver -e arraymod | grep -v grep
set +x

[Shantaram Sahyadri]

Hi,

the output of what command is

# what `which grep`
/usr/bin/grep:
$Revision: B.11.11_LR
Fri Oct 27 00:57:38 PDT 2000 $

[Andrew Merritt_2]

> here is the line as it is in the script


>GREP=/usr/bin/grep
>set -x
>ps -eaf | $GREP -i -e armserver -e arraymod | grep -v grep
>set +x

Two comments on this:
Firstly, you're using $GREP for one call, and just 'grep' for the other, not $GREP for both as suggested in an earlier response. As others have suggested, we'd need to see the path for 'grep' within the script.

Secondly, what is the output when you run this - what does the -x output show for this line?

Andrew

[harry d brown jr]

The what+which indicates you have the correct grep command.

Try this at the COMMAND LINE:

GREP=/usr/bin/grep
ps -eaf | ${GREP} -i -e armserver -e arraymod | ${GREP} -v grep

live free or die
harry d brown jr

[john korterman]

Hi,
you stated in an earlier post that you tried using the UNIX95 option. Can you confirm that UNIX95 is not set in you script? I have the idea that setting this variable may - in connection with executing ps - cause some disturbance as to what may be considered options to the ps command(!).
Just an idea, but try inserting:
unset UNIX95
just before the grep command.

regards,
John K,

[Michael Schulte zur Sur]

John,

UNIX95 influences ps but I found not reference to an influence in grep.

Michael

[Bill Hassell]

If you are looking for a specific program name, then your command line can be simplified to:

UNIX95= ps -fC armserver

UNIX95 turns on additional options in grep, -C being the most useful. ps -e is very intrusive on a busy system which is why it's best to let ps (and not grep) look for the processes by name. You can use multiple -C options just like -e in grep:

UNIX95= ps -f -C armserver -C arraymond

[john korterman]

Hi again,
Michael, I did not dare to directly present the perhaps crazy idea that $GREP might somehow in this context be considered an option to the ps command.
Maybe I will now.....

regards,
John K.

[Shantaram Sahyadri]

hello people,

Thank you all for your inputs and support,

I think I will stick with UNIX95 option and use Bill's option of using -C with ps, I have replaced the lines and works fine in all patforms. So I am going to let grep as it is and closing this thread.

[Shantaram Sahyadri]

hi,

thread closed