Re: [Help-bash] trap when expected return value may be non-zero?

[adrelanos]

Bob Proulx:
> adrelanos wrote:
>> I have a global trap, but in one function I am expecting a non-zero
>> return code. Example:
>>
>> trap "error_handler" ERR INT TERM
> 
> I can't really define it but it makes me squirm to see ERR bundled
> together with INT and TERM.  (And if you are catching INT and TERM why
> not HUP and QUIT?  Seems like an omission.)

Yes, I should think about HUP and QUIT.

HUP (Hang up detected on controlling terminal or death of controlling
process) should be definitively added.

INT (Issued if the user sends an interrupt signal (Ctrl + C).) is in,
because users of my build scripts are free to press Ctrl + C to
interrupt them for whatever reason. What it does is informing about the
last $BASH_COMMAND, cleaning up, dismounting an image (because not doing
so and re-running the build script while the image is still mounted
could lead to strange errors).

TERM (Software termination signal (sent by kill by default).) If one
thinks "build script takes to long, I forgot to add some files" and uses
kill to stop it, it's best to do the same cleanup as for INT.

ERR (Non-expected non-zero return code in rare cases (bugs).) Same
information and cleanup as if INT or TERM.

SIGQUIT (Issued if the user sends a quit signal (Ctrl + D).) Well, I
think Ctrl + C is more common than Ctrl + D. If one really wants this
and stops my scripts this way, so be it. I think having one way to stop
it while cleaning and and one just exiting is good.

> If you search the lists you will find much discussion and opinions
> about 'set -e'.  It is a very polarized issue.  People either love it
> or hate it.  And ERR is right in the middle of it too.
> 
> The problem I see above is that ERR isn't really bundled to INT or
> TERM and so trying to bundle them together feels incorrect to me.  If
> you are just doing something for debugging that is one thing.  But I
> would never want to see that in production code.  If that were passed
> through my keyboard the first thing I would do is remove the ERR
> trap.  That is just my opinion and style and it differs from others
> who like set -e behavior.
> 
> I recommend avoiding ERR and set -e.  There are limited times when
> they are useful.  But I don't think they are generally useful.  In
> general their use tends to cause many problems.
> 
> Here is a reference to read up on it.
> 
>   http://mywiki.wooledge.org/BashFAQ/105

I've seen that one, that's why I use trap ERR. trap ERR works well for
me. I caused a bug, where in rare cases where let/expr returned non-zero
values. Since some of my scripts run in background and are using
graphical zentiy/kdialog notifications, set -e doesn't work for me. trap
ERR just shows a info text, $scriptname, $BASH_COMMAND, encourages
writing a bug report and exists.

>> examplefunct() {
>>    # code...
>>
>>    service someservice status
>>    returncode="$?"
>>
>>    # more code...
>> }
>>
>> When service return a non-zero value, the error_handler is called.
> 
> Right.  Because you have set the ERR trap.
> 
>> So I have to work around it. Example:
> 
> So you are working around your own code?  I think now you see the
> point of why doing it that way feels bad.  It feels like you are
> working against yourself.
> 
>> trap "error_handler" ERR INT TERM
>>
>> examplefunct() {
>>    # code...
>>
>>    trap "" ERR INT TERM
>>    service someservice status
>>    local returncode="$?"
>>    trap "error_handler" ERR INT TERM
>>
>>    # more code...
>> }
>>
>> Well, it works, but thats not so pretty.
> 
> And you have disabled INT and TERM during that same time period.  If
> you needed them otherwise then you have a bug because during that time
> period they are disabled.  And if you don't need them then it is still
> a bug because you have them otherwise.

>> Basically, I just want to the trap being called in case something really
>> unexpected happens. Most times I use traps as a way to find bugs in my
>> scripts. In this case, for example if "service" wouldn't exist (not in
>> $PATH or whatever) or if "someservice" wouldn't exist..
> 
> If I am checking status then I will expect a good confirmation of a
> running service and anything that isn't that will be interpreted that
> the service is offline.

Agreed. The "service" was just an example for such rare cases. Other
rare cases with non-zero return values coming to my mind include grap
and id.

> If I am starting a service then I will explicitly check for errors and
> handle them for that start.  It is unlikely that a generic any-failure
> type of exception handler will know what to do correctly.

The only thing it correctly does is informing, which command failed and
exit.