aborting a bash script with control-c
in [Shell]
|
From: Michael Paoli on 29 May 2010 10:45 On May 27, 3:25 pm, "Russ P." <russ.paielli(a)gmail.com> wrote: > I would like to be able to abort a bash script with control-c when I > can see that something has gone awry. However, it often doesn't work, > depending on exactly when you hit control-c, because the script has > spawned other scripts, and control-c only apparently only aborts the > one that happens to be currently executing. What do I need to put in > the original script to ensure that control-c aborts the whole > enchilada? Thanks. trap 'abort whole enchilada' 2 # don't have this shell (prematurely) remove the trap noted above # don't have this shell itself exec another program # do have this script wait until other parts of interest are all # completed before exiting
From: Russ P. on 29 May 2010 17:33 On May 29, 3:30 am, Thomas 'PointedEars' Lahn <PointedE...(a)web.de> wrote: > Russ P. wrote: > > I am aware of "trap," but I am not sure exactly what it does. > > You could RTFM. Actually, I did RTFM. I also referred to an O'Reilly book on Bash. Perhaps I missed, but I did not see the answer to my question. Here's a suggestion for you: 1) If you don't like my question(s), please don't reply to my posts. 2) If you can't or won't answer my question(s) directly, without snide remarks, please don't reply to my posts. > > Suppose I have this near the top of my bash script: > > > trap 'exit' INT TERM # exit when interrupted or terminated > > > Is this guaranteed to cause the script and all of the subprocesses > > that it has spawned to terminate when I hit control-C? > > If you use the proper signal names, it is guaranteed to terminate the shell. And just what might those "proper signal names" be? I see "INT" and "TERM" used in online tutorials. Are they somehow improper? Please recall my suggestions above. Thanks. Russ P.
From: Jon LaBadie on 30 May 2010 01:22 Russ P. wrote: > On May 29, 3:30 am, Thomas 'PointedEars' Lahn <PointedE...(a)web.de> > wrote: >> Russ P. wrote: >>> I am aware of "trap," but I am not sure exactly what it does. >> You could RTFM. > > Actually, I did RTFM. I also referred to an O'Reilly book on Bash. > Perhaps I missed, but I did not see the answer to my question. Here's > a suggestion for you: > > 1) If you don't like my question(s), please don't reply to my posts. > > 2) If you can't or won't answer my question(s) directly, without snide > remarks, please don't reply to my posts. > >>> Suppose I have this near the top of my bash script: >>> trap 'exit' INT TERM # exit when interrupted or terminated >>> Is this guaranteed to cause the script and all of the subprocesses >>> that it has spawned to terminate when I hit control-C? >> If you use the proper signal names, it is guaranteed to terminate the shell. > > And just what might those "proper signal names" be? I see "INT" and > "TERM" used in online tutorials. Are they somehow improper? Please > recall my suggestions above. Thanks. Don't be thin-skinned when posting in forums such as c.u.s. Signals are notifications to a process from the kernel that some event has taken place. They are named and also enumerated so the process can tell what event took place. See signal(7) in TFM for a list of 30 or more. Often, but certainly not always, the event has negative implications for the process; try to divide by 0.0 and the math coprocessor will send signal 8. Log off and your process will get signal 1. A couple of signals can be generated from the keyboard, eg. interupt (INT) or signal 2, and the kill command can be used to send any desired signal but by default sends the "request to terminate" (TERM) signal 15. BTW Commands dealing with signals generally will work with numbers or abbreviated names. Your trap example could have been "trap 'exit' 2 15". However the numbers assigned to various signals is traditional, not guarenteed. Thus T"PE"L's admonition to use "proper signal names". For most signals, a process can choose what action, if any, it will take when receiving each type of signal. "trap" is the mechanism by which a shell script specifies what should happen when various signals are received. Signals are only acted upon when a process is transitioning from executing user code to executing kernel code. So if a process is stuck in some driver code that will never return, your interrupt signal will be acted upon. Each process can set up its own signal handling. So if your shell script executes any subprocesses, they may respond to an interrupt signal differently than the parent. So no, your trap command does not guarantee all of the subprocesses will be terminated.
From: Russ P. on 30 May 2010 02:05 On May 29, 10:22 pm, Jon LaBadie <jlaba...(a)aXcXm.org> wrote: > Signals are notifications to a process from the kernel that some event > has taken place. They are named and also enumerated so the process can > tell what event took place. See signal(7) in TFM for a list of 30 or more. > Often, but certainly not always, the event has negative implications > for the process; try to divide by 0.0 and the math coprocessor will > send signal 8. Log off and your process will get signal 1. > > A couple of signals can be generated from the keyboard, eg. interupt (INT) > or signal 2, and the kill command can be used to send any desired signal > but by default sends the "request to terminate" (TERM) signal 15. > > BTW Commands dealing with signals generally will work with numbers or > abbreviated names. Your trap example could have been "trap 'exit' 2 15". > However the numbers assigned to various signals is traditional, not guarenteed. > Thus T"PE"L's admonition to use "proper signal names". > > For most signals, a process can choose what action, if any, it will take > when receiving each type of signal. "trap" is the mechanism by which a > shell script specifies what should happen when various signals are received. > > Signals are only acted upon when a process is transitioning from executing > user code to executing kernel code. So if a process is stuck in some > driver code that will never return, your interrupt signal will be acted upon. > > Each process can set up its own signal handling. So if your shell script > executes any subprocesses, they may respond to an interrupt signal differently > than the parent. So no, your trap command does not guarantee all of the > subprocesses will be terminated. Thanks for that explanation. The problem is not so much that I want the subprocesses terminated, but rather that I want the main parent process terminated. Here's the situation. Say I have a bash script called "runOneCase." And say I also have a script called "runAllCases," which starts "runOneCase" 100+ times in series (no &) for each of 100 different input data files. I run this script many times. Occasionally something goes wrong, and I can see from the output that each case is bombing, so I just want to stop the whole thing and fix the bug. When I hit ctrl-c, however, it only kills the currently executing "runOneCase," then the next one starts. I keep hitting ctrl-c, but the darn thing just keeps going until finally I get lucky and hit it between executions of "runOneCase." I just want to have the first ctrl-C kill the main script, "runAllCases." I actually figured out myself that trap 'exit' INT TERM # exit when interrupted or terminated in the main script is probably what I need, but I just wanted confirmation. I really could have done without the RTFM. I did not see this particular problem explicitly discussed in any of the docs, but I certainly could have missed it. Russ P.
From: Thomas 'PointedEars' Lahn on 31 May 2010 08:48
Russ P. wrote: > Thomas 'PointedEars' Lahn wrote: >> Russ P. wrote: >> > I am aware of "trap," but I am not sure exactly what it does. >> >> You could RTFM. > > Actually, I did RTFM. I also referred to an O'Reilly book on Bash. > Perhaps I missed, but I did not see the answer to my question. Here's > a suggestion for you: > > 1) If you don't like my question(s), please don't reply to my posts. > > 2) If you can't or won't answer my question(s) directly, without snide > remarks, please don't reply to my posts. <http://www.catb.org/~esr/faqs/smart-questions.html#not_losing> PointedEars |