trap question

trap question

Post by Jungle Li » Tue, 16 Jul 2002 12:16:29



Hi:
Woud you please ask me a question about trap?
I use trap as below:

#!/usr/bin/ksh
trap 'echo Do not stop the proceiss'  1 2 3 15
tar -xvf /tmp.tar /tmp1
cp ..... ....
cp .... ....
trap -

I press Ctrl-C when the process is executing 'untar',  the
message 'Do not stop the process' prompt,  then the
process exist quickly. I check the result and found the
untar does not finish but two files has been copied.

That teams, By using trap to catch the signal then call its
 actions, ksh can not return to the original executing point.

How can I meet the requirement?

1. Trap Ctrl-C, echo some warning messages
2. Then continue original command execution.

Jungle

 
 
 

trap question

Post by Malcolm Dew-Jon » Wed, 17 Jul 2002 04:07:28


: Hi:
: Woud you please ask me a question about trap?
: I use trap as below:

: #!/usr/bin/ksh
: trap 'echo Do not stop the proceiss'  1 2 3 15
: tar -xvf /tmp.tar /tmp1
: cp ..... ....
: cp .... ....
: trap -

: I press Ctrl-C when the process is executing 'untar',  the
: message 'Do not stop the process' prompt,  then the

on bash

$ help trap

trap: trap [arg] [signal_spec ...] or trap -l

    If ARG is the null string each
    SIGNAL_SPEC is ignored by the shell and by the commands it invokes.

So perhaps

        trap '' 1 2 3 15

I would guess ksh is similar.

 
 
 

trap question

Post by Barry Margoli » Wed, 17 Jul 2002 05:30:35




>Hi:
>Woud you please ask me a question about trap?

You're asking, we're answering. :)

Quote:>I use trap as below:

>#!/usr/bin/ksh
>trap 'echo Do not stop the proceiss'  1 2 3 15
>tar -xvf /tmp.tar /tmp1
>cp ..... ....
>cp .... ....
>trap -

>I press Ctrl-C when the process is executing 'untar',  the
>message 'Do not stop the process' prompt,  then the
>process exist quickly. I check the result and found the
>untar does not finish but two files has been copied.

>That teams, By using trap to catch the signal then call its
> actions, ksh can not return to the original executing point.

The ksh man page says:

            Traps are not processed while a job is waiting for  a
            foreground  process.   Thus,  a trap on CHLD won't be
            executed until the foreground job terminates.

When you press Ctrl-C a signal is sent to *both* the shell and the tar
processes.  The shell doesn't process the signal immediately, as it says
above.  But when the tar process gets the signal, it is killed.  Then the
shell performs the echo command and continues with the script.

Quote:>How can I meet the requirement?

>1. Trap Ctrl-C, echo some warning messages
>2. Then continue original command execution.

As the other poster suggested, the best you can do is ignore the signals
entirely.  This will prevent the user from interrupting the tar (unless
they use Ctrl-\, which can't be trapped or ignored), but won't print a
warning.

--

Genuity, Woburn, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.

 
 
 

trap question

Post by Dan Merc » Wed, 17 Jul 2002 22:55:10






>>Hi:
>>Woud you please ask me a question about trap?

> You're asking, we're answering. :)

>>I use trap as below:

>>#!/usr/bin/ksh
>>trap 'echo Do not stop the proceiss'  1 2 3 15
>>tar -xvf /tmp.tar /tmp1
>>cp ..... ....
>>cp .... ....
>>trap -

>>I press Ctrl-C when the process is executing 'untar',  the
>>message 'Do not stop the process' prompt,  then the
>>process exist quickly. I check the result and found the
>>untar does not finish but two files has been copied.

>>That teams, By using trap to catch the signal then call its
>> actions, ksh can not return to the original executing point.

> The ksh man page says:

>             Traps are not processed while a job is waiting for  a
>             foreground  process.   Thus,  a trap on CHLD won't be
>             executed until the foreground job terminates.

> When you press Ctrl-C a signal is sent to *both* the shell and the tar
> processes.  The shell doesn't process the signal immediately, as it says
> above.  But when the tar process gets the signal, it is killed.  Then the
> shell performs the echo command and continues with the script.

>>How can I meet the requirement?

>>1. Trap Ctrl-C, echo some warning messages
>>2. Then continue original command execution.

> As the other poster suggested, the best you can do is ignore the signals
> entirely.  This will prevent the user from interrupting the tar (unless
> they use Ctrl-\, which can't be trapped or ignored), but won't print a
> warning.

Quit can be trapped or ignored - but that won't help in this situation.
Signals generated by a terminal are sent to all processes with the same
process group leader as the process controlling the terminal when
the signal is generated.  So trapping a signal in the shell won't
prevent it from being sent to tar.  There are ways of preventing
this - by putting tar into a separate process group:

   (tar ...&)

but then you have the problem of knowing when the tar is done.
You could,  for instance:

   tarpid=$(tar ...&;echo $!)

   while kill -0 $tarpid;do sleep 1;done

Or you could use a FIFO and wait on the FIFO:

   FIFO=$(mktemp -d ~ fifo)
   trap "rm -f $FIFO" exit
   trap 'print -u2 "QUIT ignored"' quit
   trap 'print -u2 "INT ignored"' int
   mkfifo $FIFO || { print -u2 "Unable to make fifo";exit 1; }
   ( (tar ...;print TARCOMPLETE:$?) >$FIFO 2>&1 &)
   exec 3<>$FIFO                       # prevent block
   while IFS=: read -u3 tar rc
      do
      [[ -z $tar ]] ||  continue       # signal trapped
      if [[ $tar = TARCOMPLETE ]]
         then
         print -u2 "tar completed with return code $rc"
         break
      else
         print "${tar}${rc:+:$rc}"
      fi
      done

Or you could simply prevent the terminal from generating the signals:

   STTY=$(stty -g)
   stty intr ^- quit ^- stop ^- start ^- susp ^- dsusp ^-
   tar ...
   stty $STTY

--
Dan Mercer

- Show quoted text -

> --

> Genuity, Woburn, MA
> *** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
> Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.

 
 
 

trap question

Post by Barry Margoli » Thu, 18 Jul 2002 00:10:06




>Quit can be trapped or ignored - but that won't help in this situation.
>Signals generated by a terminal are sent to all processes with the same
>process group leader as the process controlling the terminal when
>the signal is generated.  So trapping a signal in the shell won't
>prevent it from being sent to tar.

But if a signal is being ignored, that is inherited by child processes.  So
if you ignore it in the shell, tar will also ignore it (I tested that case
myself).

--

Genuity, Woburn, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.

 
 
 

trap question

Post by Chet Ram » Thu, 18 Jul 2002 01:23:40



>Quit can be trapped or ignored - but that won't help in this situation.
>Signals generated by a terminal are sent to all processes with the same
>process group leader as the process controlling the terminal when
>the signal is generated.  So trapping a signal in the shell won't
>prevent it from being sent to tar.  There are ways of preventing
>this - by putting tar into a separate process group:

Use job control.  `set -o monitor' works just as well in shell scripts
as interactively, and will put child processes into separate process
groups.  You can then use `wait' (with perhaps some fiddling to make
sure that the wait continues after the parent ksh traps a signal) to
await tar's completion.

I have not tested this.

Chet
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
( ``Discere est Dolere'' -- chet )


 
 
 

trap question

Post by Dan Merc » Thu, 18 Jul 2002 03:36:42






>>Quit can be trapped or ignored - but that won't help in this situation.
>>Signals generated by a terminal are sent to all processes with the same
>>process group leader as the process controlling the terminal when
>>the signal is generated.  So trapping a signal in the shell won't
>>prevent it from being sent to tar.

> But if a signal is being ignored, that is inherited by child processes.  So
> if you ignore it in the shell, tar will also ignore it (I tested that case
> myself).

Right. If you ignore it,  the child ignores it.  But if you trap it,
the child follows default behavior unless the child explicitly traps it.

   $ cat traptest
   #!/usr/bin/ksh
   trap "$1" int
   SECONDS=0
   print start
   sleep 10
   print end:$SECONDS
   $ traptest
   start
   ^C
   end:10
   $ traptest :
   start
   ^C
   end:1

One other process - trap ignore int and quit,  start tar as a
co-process, then trap catch int and quit - the following worked
quite nicely for me:

      #!/usr/bin/ksh

      trap "" int quit
      tar cvf /tmp/me.tar ~ |&
      trap 'echo int caught' int
      trap 'echo quit caught' quit
      while read -p
         do
         print -- "$REPLY"
         done

--
Dan Mercer

> --

> Genuity, Woburn, MA
> *** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
> Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.

 
 
 

trap question

Post by Dan Merc » Thu, 18 Jul 2002 04:15:05





>>Quit can be trapped or ignored - but that won't help in this situation.
>>Signals generated by a terminal are sent to all processes with the same
>>process group leader as the process controlling the terminal when
>>the signal is generated.  So trapping a signal in the shell won't
>>prevent it from being sent to tar.  There are ways of preventing
>>this - by putting tar into a separate process group:

> Use job control.  `set -o monitor' works just as well in shell scripts
> as interactively, and will put child processes into separate process
> groups.  You can then use `wait' (with perhaps some fiddling to make
> sure that the wait continues after the parent ksh traps a signal) to
> await tar's completion.

> I have not tested this.

> Chet
> --
> ``The lyf so short, the craft so long to lerne.'' - Chaucer
> ( ``Discere est Dolere'' -- chet )



Cool idea and it works,  though it's tricky.  tar continues to run,
error messages print,  but wait gets interrupted so you have to
wait in a while loop:

   #!/usr/bin/ksh

   set -o monitor

   trap 'echo signal caught' int quit
   (tar cf /tmp/me.tar ~/devel/src;return 9) &
   echo "Waiting for tar"
   rc=0
   while ((!rc))
      do
      lastrc=$rc
      wait $!
      rc=$?
      done
   echo "tar completed with rc=$lastrc"

I had to use wait pid because I couldn't finda way to differentiate
between a wait that had no more children to wait for and one that was
interrupted.

--
Dan Mercer

 
 
 

1. Trap question

Hi all,

Running on E450 and Solaris 8.
I want to know if it is possible in a script to trap the first CTRL-D
sequence and says to the user : "First time you type CTRL-D - the second
time will exit the program".
Then, if the user types on CTRL-D a second time it will exit the program and
said to the user "Sorry, you type twice on CTRL-D, exiting program !!!"

How can I do this in a shell script by using the trap command ???

Thanks.

Chris.

2. error running make

3. trap question

4. gnome 2.0

5. ksh - trap question

6. Where is the documentation for nisctl for NIS+?

7. Bad trap Question

8. ttys and serial printer rs-422 with AIX 4.3.1

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

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

11. Trip Trap Trip Trap on my bridge.

12. ksh and trap...(how to release trap?).

13. PANIC: K-TRAP KERNAL MODE TRAP TYPE 0x0000006