aborting a bash script with control-c
in [Shell]
|
From: Kenny McCormack on 31 May 2010 09:23 In article <31123255.pHGDlbCDJk(a)PointedEars.de>, Thomas 'PointedEars' Lahn <usenet(a)PointedEars.de> wrote: >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> I think ESR would not be pleased to see what you schmucks are doing in his name. -- Just for a change of pace, this sig is *not* an obscure reference to comp.lang.c...
From: Russ P. on 31 May 2010 15:25 On May 31, 5:48 am, Thomas 'PointedEars' Lahn <PointedE...(a)web.de> wrote: > <http://www.catb.org/~esr/faqs/smart-questions.html#not_losing> > > PointedEars Sorry, PointyHead, but I have far more important things to do than to read an 80-page document to learn your idea of "etiquette." Here's basic common sense: if you think I'm ignorant or don't ask good questions, and you can't bring yourself to answer my questions politely, then just don't reply. You won't waste your time or mine. I wouldn't mind your rudeness quite as much if you actually answered my question, but you don't even do that much. I am always amused by people who think they are the alpha dog on some obscure usenet group. Who do you think you are impressing, other than yourself? These groups are for getting answers, not for building a resume' or showing off your knowledge. If you think I am in awe of your knowledge, you are sadly mistaken. Bash is just one of several software tools that I use, and one of the less interesting ones at that. But it's quirks make a delight for pedants.
From: Jerry Peters on 31 May 2010 16:26 Russ P. <russ.paielli(a)gmail.com> wrote: > 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. I suspect your problem is that the _child_ is getting the SIGINT, not the parent. Does the runOneCase script set a valid exit status? If so you could do something like: if ! runOneCase; then exit fi You could also use a counter & only exit after a certain number of processes have failed. Or you could test for it receiving a signal: runOneCase if [ $? -gt 127 ]; then exit fi or a specific test for SIGINT: if [ $? -eq 130 ]; then exit fi These last 2 rely on the exit status being the signal number which terminated the process + 128. Jerry
From: Seebs on 2 Jun 2010 00:04 On 2010-05-31, Russ P. <russ.paielli(a)gmail.com> wrote: > Sorry, PointyHead, but I have far more important things to do than to > read an 80-page document to learn your idea of "etiquette." It does not seem as though you do. > Here's > basic common sense: if you think I'm ignorant or don't ask good > questions, and you can't bring yourself to answer my questions > politely, then just don't reply. You won't waste your time or mine. Ahh, but you'll keep wasting everyone else's time, whereas, if you'd taken the very good advice you were given, you would have ceased to waste peoples' time and started getting much better answers much more quickly. BTW, "alpha dogs" is the wrong model. You need help. I happen to be a moderately qualified expert in the field in which you need help. Normally, when people want me to spend time helping them, they pay me. Because I'm generally a helpful sort, I also hang around on Usenet, helping people for free. Since I have a finite life expectancy, though, I have to do triage; I have to pick some questions to answer and leave others alone. My strategy is that I'll answer well-asked questions more often than vague ones. And, as a bonus, I also answer questions from friendly people more often than I answer questions from jerks. See, this way, I'm contributing to the general success of people who are polite and friendly. Which is to say: I probably know the answer to your question, but it is my considered opinion that to answer your question, without telling you about the much more significant problem you haven't considered, would do you a grave disservice, because I'd be enabling your destructive -- and ultimately self-destructive -- behaviors. So no answers for you, and into the killfile you go. If you keep this up, you will eventually run out of experts to answer your questions, because you're too busy fighting for dominance to think about a *cooperative* model, in which there are no alpha dogs, just people (primates, even!) who are trying to do the best and most efficient job they can of sharing information. Back in 1990, when I asked questions, people lectured me about how to ask better questions. I paid attention, I asked better questions, and they were super helpful to me. Neat, huh! It's almost as though, when I'm asking people to do me a favor, it's a good idea to treat them with some kind of respect. -s -- Copyright 2010, all wrongs reversed. Peter Seebach / usenet-nospam(a)seebs.net http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
From: Chris F.A. Johnson on 2 Jun 2010 04:06
On 2010-06-02, Russ P. wrote: > Oh, golly gosh, what will I do now without your help? It's not just Peter you are alienating; it's everyone who might help you. Even "Pointyhead" sometimes answers questions correctly. PLONK -- Chris F.A. Johnson, author <http://shell.cfajohnson.com/> =================================================================== Shell Scripting Recipes: A Problem-Solution Approach (2005, Apress) Pro Bash Programming: Scripting the GNU/Linux Shell (2009, Apress) ===== My code in this post, if any, assumes the POSIX locale ===== ===== and is released under the GNU General Public Licence ===== |