Hi,

We have a trap statement for every non zero returning command/function.


Due to a recent change, we have to grep for some string in a fixed
file. There are functional actions associated for each of the
situations (when its found and not found).

However, when the grep command does not match any lines in the input
file, returns zero as its exit code. Unfortunately that is caught by
the trap.

We really really need to avoid the "grep" being "trapped" by trap
command.

Are their any possibilities ? We want to avoid changing the design
involving the use of trap in and around the trap statement.

All suggestions are appreciated.

regards
raghav..

[ Post a follow-up to this message ]

sharma.raghvendra@gmail.com wrote:
> Hi,
>
> We have a trap statement for every non zero returning command/function.
>
>
> Due to a recent change, we have to grep for some string in a fixed
> file. There are functional actions associated for each of the
> situations (when its found and not found).
>
> However, when the grep command does not match any lines in the input
> file, returns zero as its exit code.

No, it returns 1 as it's exit code if it doesn't match. grep returns
zero if it does match.

Unfortunately that is caught by
> the trap.
>
> We really really need to avoid the "grep" being "trapped" by trap
> command.
>
> Are their any possibilities ? We want to avoid changing the design
> involving the use of trap in and around the trap statement.
>
> All suggestions are appreciated.

You could use awk instead of grep so you can control the exit status. e.g.

$ cat t1
stuff
$ grep stuff t1
stuff
$ echo $?
0
$ grep garbage t1
$ echo $?
1
$ awk '/stuff/' t1
stuff
$ echo $?
0
$ awk '/garbage/' t1
$ echo $?
0
$ awk '/stuff/{code=1;print}END{exit code}' t1
stuff
$ echo $?
1
$ awk '/garbage/{code=1;print}END{exit code}' t1
$ echo $?
0
$ awk '/stuff/{code=1;print}END{exit !code}' t1
stuff
$ echo $?
0
$ awk '/garbage/{code=1;print}END{exit !code}' t1
$ echo $?
1

There may be better ways around your problem - you should post a small
sample script that exhibits the behavior with sample input and desired
output.

Ed.

[ Post a follow-up to this message ]

Ed Morton wrote:

<snip>
> You could use awk instead of grep so you can control the exit status. e.g.

Or, if you just want the exit status to be zero regardless of whether or
not your pattern matched, you could just use sed:

$ sed -n '/stuff/p' t1
stuff
$ echo $?
0
$ sed -n '/garbage/p' t1
$ echo $?
0

Ed.

[ Post a follow-up to this message ]

Ed Morton <morton@lsupcaemnt.com> writes:

> sharma.raghvendra@gmail.com wrote: 
>
> No, it returns 1 as it's exit code if it doesn't match. grep returns
> zero if it does match.
>
>   Unfortunately that is caught by 
>
> You could use awk instead of grep so you can control the exit status. e.g.
>
> $ cat t1
> stuff
> $ grep stuff t1
> stuff
> $ echo $?
> 0
> $ grep garbage t1
> $ echo $?
> 1

action_found () {
echo found
}
action_not_found () {
echo not found
}
$ grep -q -s stuff t1 && action_found || action_not_found
found
$ echo $?
0
$ grep -q -s garbage t1 && action_found || action_not_found
not found
$ echo $?
0


--
__Pascal Bourguignon__                     http://www.informatimago.com/
-----BEGIN GEEK CODE BLOCK-----
Version: 3.12
GCS d? s++:++ a+ C+++ UL++++ P--- L+++ E+++ W++ N+++ o-- K- w---
O- M++ V PS PE++ Y++ PGP t+ 5+ X++ R !tv b+++ DI++++ D++
G e+++ h+ r-- z?
------END GEEK CODE BLOCK------

[ Post a follow-up to this message ]

On 2005-07-13, sharma.raghvendra@gmail.com wrote:
> Hi,
>
> We have a trap statement for every non zero returning command/function.

Don't.

> Due to a recent change, we have to grep for some string in a fixed
> file. There are functional actions associated for each of the
> situations (when its found and not found).
>
> However, when the grep command does not match any lines in the input
> file, returns zero as its exit code. Unfortunately that is caught by
> the trap.
>
> We really really need to avoid the "grep" being "trapped" by trap
> command.

Don't use trap; check the exit status of the command.

> Are their any possibilities ? We want to avoid changing the design
> involving the use of trap in and around the trap statement.

The design is inappropriate for your script; change it.

--
Chris F.A. Johnson                     <http://cfaj.freeshell.org>
 ========================================
==========================
Shell Scripting Recipes: A Problem-Solution Approach, 2005, Apress
<http://www.torfree.net/~chris/books/cfaj/ssr.html>

[ Post a follow-up to this message ]

Chris F.A. Johnson wrote:
> On 2005-07-13, sharma.raghvendra@gmail.com wrote:
> 
>
>
>     Don't.

I don't make a habit of disagreeing with CFAJ but must make an exception
in this case. Using a trap on ERR in shell programming turns it into an
exception-throwing language like Java[*]; you can catch the exceptions
(non-zero exit statuses) that you care about as special cases and all
others result in fatal errors. It's as robust a shell programming style
as I know. If using ksh or bash you can add useful data such as

trap 'echo Failed at $0:$LINENO >&2' ERR
 
>
>
>     The design is inappropriate for your script; change it.

I always tell people to add a new shell builtin to their lexicon: "||:"
(without the quotes). Of course it's really two old builtins jammed
together to mean "ignore preceeding exit status". In other words
'>/dev/null' means "throw away stdout", '2>/dev/null' means "throw away
stderr", and '||:' means "throw away return code". So you take your grep
command, and any others for which you don't want to fail on failure, and
stick ||: on the end:

grep foobar /etc/motd ||:

[*] The merits of exceptions vs manual error checking can be and have
been debated in other places; I simply note that the exception style
cannot be said to be "wrong", though some may not be used to or prefer
it. I happen to think you can't write a large reliable shell script
without it.

--
Henry Townsend

[ Post a follow-up to this message ]

On 2005-07-13, Henry Townsend wrote:
> Chris F.A. Johnson wrote: 
>
> I don't make a habit of disagreeing with CFAJ but must make an exception
> in this case. Using a trap on ERR in shell programming turns it into an
> exception-throwing language like Java[*]; you can catch the exceptions
> (non-zero exit statuses) that you care about as special cases and all
> others result in fatal errors.

That is something I rarely want to happen, especially not in
large, complicated scripts. For those few cases, I prefer a
function like die:

die()
{
result=$1
shift
[ $# -ge 1 ] && printf "%s\n" "$*" >&2
exit $result
}

..and I call it when a command fails:

some_command | die $? "You messed up"


> It's as robust a shell programming style as I know. If using ksh or
> bash you can add useful data such as

If you aren't using ksh or bash, trapping ERR may not work, since
it is not required by POSIX.

> 	trap 'echo Failed at $0:$LINENO >&2' ERR
 
>
> I always tell people to add a new shell builtin to their lexicon: "||:"
> (without the quotes). Of course it's really two old builtins jammed
> together to mean "ignore preceeding exit status". In other words
> '>/dev/null' means "throw away stdout", '2>/dev/null' means "throw away
> stderr", and '||:' means "throw away return code". So you take your grep
> command, and any others for which you don't want to fail on failure, and
>   stick ||: on the end:
>
> 	grep foobar /etc/motd ||:
>
> [*] The merits of exceptions vs manual error checking can be and have
> been debated in other places; I simply note that the exception style
> cannot be said to be "wrong", though some may not be used to or prefer
> it.

Agreed.

> I happen to think you can't write a large reliable shell script
> without it.

I disagree. I do it all the time.

--
Chris F.A. Johnson                     <http://cfaj.freeshell.org>
 ========================================
==========================
Shell Scripting Recipes: A Problem-Solution Approach, 2005, Apress
<http://www.torfree.net/~chris/books/cfaj/ssr.html>

[ Post a follow-up to this message ]

Chris F.A. Johnson wrote:
> On 2005-07-13, Henry Townsend wrote: 
>
>
>     If you aren't using ksh or bash, trapping ERR may not work, since
>     it is not required by POSIX.

Of course, but where we came in was that the OP has an existing stable
script which has always done trap on ERR. So presumably he's using a
shell which supports it.

--
Henry Townsend

[ Post a follow-up to this message ]

Zawartość nagłówka ["Followup-To:" comp.unix.shell.]
On 13.07.2005, Pascal Bourguignon <pjb@informatimago.com> wrote:
> Ed Morton <morton@lsupcaemnt.com> writes:
> 
>
> action_found () {
>    echo found
> }
> action_not_found () {
>    echo not found
> }
> $ grep -q -s stuff t1 && action_found || action_not_found
> found
> $ echo $?
> 0
> $ grep -q -s garbage t1 && action_found || action_not_found
> not found
> $ echo $?
> 0

You made a logical error. $? contains return status of command *most*
*recently* executed. In this case it is action_found or
action_not_found, both returning status of echo, which is 0. Try this:

$ grep -q -s stuff t1; echo $?
$ grep -q -s garbage t1; echo $?

--
Feel free to correct my English
Stanislaw Klekot

[ Post a follow-up to this message ]

In article <Zc2dnZZqfpP6A0jfRVn-2A@comcast.com>,
Henry Townsend  <henry.townsend@not.here> wrote:
>Chris F.A. Johnson wrote: 
>
>I don't make a habit of disagreeing with CFAJ but must make an exception
>in this case.

Don't be afraid to disagree with CFAJ.  His comments, though technically
correct, are rarely useful.  It's just like in (the joke newsgroup known,
somewhat comically, as) comp.lang.c.  The topic is defined so narrowly and
absurdly that the answers, though technically correct, are useless.

Note, especially, his ridiculous assertion that using "trap ERR" is wrong
because it isn't POSIX and thus, not guaranteed to be present in every
(POSIX) shell.  But the OP was already using it (in a large script in an
existing environment, neither of which were going to change)!  So, that
complaint is obviously bogus.

[ Post a follow-up to this message ]