aborting a bash script with control-c
in [Shell]
|
From: Kenny McCormack on 3 Jun 2010 09:06 In article <291608c7-3290-4de5-946f-41749c862446(a)n37g2000prc.googlegroups.com>, Russ P. <russ.paielli(a)gmail.com> wrote: .... >Is this guy delusional or what? The short answer is "yes". I understand that your position on all this is "I've gotten my answer - or as much as I'm going to get from these clowns - and I'm done with this. I have a real life to take care of.", but if you are interested in reading up on this Seebs character, I advise you to go on over to comp.lang.c, where his neuroses are a perpetual topic of conversation (there being nothing else to discuss about the C language that isn't covered in the available standards documents, FAQs, etc). You will learn much. Note to other readers: I don't necessarily agree with all (or even most) of what Spinny says, but he does have Seebs's number to a T. >Where did I "demand" that anyone >answer my question? I did no such thing. I simply requested that, if >you can't or won't answer my question, then don't reply. And please >don't reply with "RTFM." You are absolutely right about the personal fiefdom aspect of all this. They can't just let you go; it would ruin their personal self-image of being "in control". -- > No, I haven't, that's why I'm asking questions. If you won't help me, > why don't you just go find your lost manhood elsewhere. CLC in a nutshell.
From: Russ P. on 3 Jun 2010 14:12 Kenny, I was just thinking about the claim you made earlier that trap 'exit' INT TERM is unnecessary in a bash script, because it is the default behavior. Then someone (with embarrassing points where he shouldn't have them) rudely replied that you were wrong. Well, I'd like to know *why* that isn't the default behavior. I have a hard time imagining a use case where I *don't* want my script to exit when I hit ctrl-c or try to kill it. And if I *did* want that behavior for some strange reason, I could easily override the default. Shouldn't behavior that the vast majority of users want, rather than behavior than virtually no one wants, be the default? So unless I'm missing something, I'd call that default behavior a significant design flaw of bash. I wonder if the experts will acknowledge that and take some initiative to correct it? But they're not paying attention to me, because I'm such an ignorant fiend. Heck, the bogus default gives them the opportunity to display their vast knowledge and insult someone else in the future, so they are probably perfectly happy with it.
From: pk on 3 Jun 2010 14:42 Russ P. 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. I suppose you can run the script in a subshell. ( runAllCases ) that way the foreground process in the process group will be the shell, which will receive the signal together with all its children.
From: Janis Papanagnou on 3 Jun 2010 15:22 Russ P. wrote: > Kenny, I was just thinking about the claim you made earlier that > > trap 'exit' INT TERM > > is unnecessary in a bash script, because it is the default behavior. > Then someone (with embarrassing points where he shouldn't have them) > rudely replied that you were wrong. Well, I'd like to know *why* that > isn't the default behavior. I have a hard time imagining a use case > where I *don't* want my script to exit when I hit ctrl-c or try to > kill it. And if I *did* want that behavior for some strange reason, I > could easily override the default. Shouldn't behavior that the vast > majority of users want, rather than behavior than virtually no one > wants, be the default? > > So unless I'm missing something, I'd call that default behavior a > significant design flaw of bash. I wonder if the experts will > acknowledge that and take some initiative to correct it? But they're > not paying attention to me, because I'm such an ignorant fiend. Heck, > the bogus default gives them the opportunity to display their vast > knowledge and insult someone else in the future, so they are probably > perfectly happy with it. > Russ, I briefly inspected one or two replies in this thread but neither found any substance nor do I see what the problem ist. I've tried with ksh as well as with bash the behaviour; of using signal defaults, of using a defined trap handler, and, of ignoring signals. It seems to me that the shells are quite transparently showing the behaviour of the underlying OS (a Unix system in my case), which is to terminate the process (per default, i.e. if there's no interrupt handler defined that specifies to do something else). I've tried different trap definitions (default, ignore, and, defined) in parent scripts and in child scripts, and the behaviour with bash and ksh is consistent and they behave as I'd expect; scripts that use the defaults terminate, scripts that ignore the signal don't terminate (and either don't forward the signal to the child). I've seem to recall to have noticed different behaviour with a bash on Cygwin, but I blamed the OS/Cygwin combo for that misbehaviour. Not sure whether my response is helful for you. Janis
From: Janis Papanagnou on 3 Jun 2010 15:30
Oh, you've been talking about background processes. Forget my reply. |