trapping and exit values

trapping and exit values

Post by Steve Knig » Wed, 15 Jul 1992 20:42:57



Apologies in advance if this is a/an FAQ.  I have, however, consulted
Kernighan & Pike, Bolsky & Korn, Timar's FAQ list, and others, without
success, and I'm curious, so...

Short summary question:  Is there any way to set up a single trap to
clean up temp files on exit (or do other stuff) and actually exit with
the value I pass to exit?  I'll take pointers to Korn shell solutions,
but I'm most interested in something that'll work for Bourne (SVR4 or
more recent), as I have to use that for the near future.

Longer discussion:  The "exit 1" in the trap in the following K&P-ish
example means I'm going to lose the actual "exit 2" or "exit 0" value
I want to exit with:

        trap 'rm -f /tmp/xyzzy; exit 1' 0 1 2 3 15

        touch /tmp/xyzzy
        echo test:
        if [ $# -gt 1 ]; then
                echo error
                exit 2
        fi
        echo success
        exit 0

Workarounds that I've tried that don't work:

        trap 'rm -f /tmp/xyzzy; exit' 0 1 2 3 15
        trap 'rm -f /tmp/xyzzy; exit $?' 0 1 2 3 15

                These exit with the value from the rm -f /tmp/xyzzy
                in the trap, i.e., 0.

        trap 'rm -f /tmp/xyzzy; exit $1' 0 1 2 3 15

                $1 evaluates to the first arg passed to the script.

        trap 'SAV=$?; rm -f /tmp/xyzzy; exit $SAV' 0 1 2 3 15

                This picks up $? from the echo command before the
                exit, i.e., 0.

So the obvious methods I can think of for trying to get at the exit
argument don't work within the trap.  Either there's some trick I
don't know about (highly possible) or it can't be done.

Ideally, I'd like to accomplish this without having to modify all the
existing exit calls in the scripts I'm working on.  Ignoring that
vague intention, doing things like creating an err_exit() function (as
in the suite of regression test scripts for ksh) will obviously work.

Otherwise, best workaround I've stumbled across is adding two lines as
follows:

        trap 'rm -f /tmp/xyzzy; exit 1' 0 1 2 3 15

        touch /tmp/xyzzy
        echo test:
        if [ $# -gt 1 ]; then
                echo error
                exit 2
        fi
        echo success
 >>       trap 0
 >>       rm -f /tmp/xyzzy
        exit 0

This at least distinguishes between zero/non-zero, but it still loses
the "exit 2" value, and has the slight drawback of duplicating the
cleanup functionality (which could be mitigated by making a single
cleanup() function...).

So, does anyone have some slick trap tricks--or a pointer to an M
they can tell me to RTF--that they'd care to share?

        Steve Knight
        uunet!cray!knight

 
 
 

trapping and exit values

Post by David W. Tamk » Thu, 16 Jul 1992 05:49:41




| Longer discussion:  The "exit 1" in the trap in the following K&P-ish
| example means I'm going to lose the actual "exit 2" or "exit 0" value
| I want to exit with:
|
|       trap 'rm -f /tmp/xyzzy; exit 1' 0 1 2 3 15
|
|       touch /tmp/xyzzy
|       echo test:
|       if [ $# -gt 1 ]; then
|               echo error
|               exit 2
|       fi
|       echo success
|       exit 0

trap 'rm -f /tmp/xyzzy; exit $outstatus' 0 1 2 3 15

touch /tmp/xyzzy
echo test:
if [ $# -gt 1 ]; then
                echo error
                outstatus=2
        # an exit command might go here but it's superfluous in the example
        else
                echo success
                outstatus=0
        # an exit command might go here but it's superfluous in the example
        fi

Since the command in the trap statement is scanned twice (once on setting up
the trap and again on exiting) and '$outstatus' is strong-quoted, it gets
evaluated at exit.

The sample works here in both sh and ksh under Dell SVR4; that is, it does
what I think Steve wants.

David W. Tamkin   Box 59297   Northtown Station, Illinois  60659-0297


 
 
 

trapping and exit values

Post by Steve Knig » Thu, 16 Jul 1992 14:56:35






> | Longer discussion:  The "exit 1" in the trap in the following K&P-ish
> | example means I'm going to lose the actual "exit 2" or "exit 0" value
> | I want to exit with:
> |
> |  trap 'rm -f /tmp/xyzzy; exit 1' 0 1 2 3 15
> |
> |  touch /tmp/xyzzy
> |  echo test:
> |  if [ $# -gt 1 ]; then
> |          echo error
> |          exit 2
> |  fi
> |  echo success
> |  exit 0

> trap 'rm -f /tmp/xyzzy; exit $outstatus' 0 1 2 3 15

> touch /tmp/xyzzy
> echo test:
> if [ $# -gt 1 ]; then
>            echo error
>            outstatus=2
>    # an exit command might go here but it's superfluous in the example
>    else
>            echo success
>            outstatus=0
>    # an exit command might go here but it's superfluous in the example
>    fi

> Since the command in the trap statement is scanned twice (once on setting up
> the trap and again on exiting) and '$outstatus' is strong-quoted, it gets
> evaluated at exit.

> The sample works here in both sh and ksh under Dell SVR4; that is, it does
> what I think Steve wants.

Yes, it undeniably works for the example, but don't be misled by the
simplicity of the example itself.  In the general case, setting an
environment variable to be evaluated by the exit trap requires going
through and setting the variable at each exit, which was the sort of
far-reaching change I was hoping to avoid.  So it's an alternative,
one I had experimented with earlier and overlooked mentioning in the
original article, but still not quite the "ideal solution" I was
hoping for.

        Steve Knight
        uunet!cray!knight

 
 
 

trapping and exit values

Post by Noah Friedm » Sat, 18 Jul 1992 20:04:01



> | Longer discussion:  The "exit 1" in the trap in the following K&P-ish
> | example means I'm going to lose the actual "exit 2" or "exit 0" value
> | I want to exit with: (deleted)

>Yes, it undeniably works for the example, but don't be misled by the
>simplicity of the example itself.  In the general case, setting an
>environment variable to be evaluated by the exit trap requires going
>through and setting the variable at each exit, which was the sort of
>far-reaching change I was hoping to avoid.  So it's an alternative,
>one I had experimented with earlier and overlooked mentioning in the
>original article, but still not quite the "ideal solution" I was
>hoping for.

   Assuming your bourne shell has a feature similar to the bash "builtin"
keyword, you can do something like the following (this example works in
bash):

        exit ()
        {
           exitstat=$1
           builtin exit $1
        }

        trap 'cleanup; builtin exit ${exitstat}' 0 1 2 3 15

Then, anywhere `exit' is called in your shell script, the function gets
executed (which eventually calls the real exit).  This avoids the need for
lots of variable frobnication everywhere else, and it enables you to have
the shell exit with a number and still have the trap work right.

Still not the perfect-world solution, but not too ugly either.

Happy shell hacking.

 
 
 

1. ksh: trap '...' exit int ... or just trap '...' exit?

trap '...' exit int ...

int will cause the script to exit, so '...' get run twice:


#!/bin/ksh

trap 'print a' exit int
sleep 10

^Ca
a

But the natural exit will always causes '...' to run,
which is often not desired.

So should we always write something like

trap 'print a' exit int
...
trap - exit
exit 0
?
--
Michael Wang
http://www.unixlabplus.com/

2. How can I detect keyboard & mouse at system run time?

3. trap "action; exit" signals = trap "action" exit?

4. studio pctv pro

5. ksh: if I trap on exit to rm tmp files, how do I save return value ?

6. Samba: how can I browse from my home PC?

7. Exit status in trapped exit function

8. Linux box as an Xterm?

9. What is this supposed to return: "trap 'exit ' 0; exit"?

10. trap on exit

11. EXIT trap and signal equivalence

12. Exit nn via trap Q

13. trap "exit" 0 1 2 3 5 safe enough?