aborting a bash script with control-c
in [Shell]
|
From: Kenny McCormack on 3 Jun 2010 17:02 In article <hu8vdh$oha$1(a)news.m-online.net>, Janis Papanagnou <janis_papanagnou(a)hotmail.com> wrote: .... >Not sure whether my response is helful for you. It isn't. It just rehashes the biblical statement of how things are supposed to work, in the theoretical cases. It says nothing about how they actually work in this one specific use case. In short, you need to go back and re-read my first post on this thread. It really does cover the situation well. (Yes, it contains both the technical answers the OP seeks, as well as important meta-information about the workings of Usenet) And, of course, you can ignore anything written that Aspbergers suffering creep who goes by the handle of "Seebs". But you know that already. -- > 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 18:05 On Jun 3, 12:30 pm, Janis Papanagnou <janis_papanag...(a)hotmail.com> wrote: > Oh, you've been talking about background processes. Forget my reply. Well, no. As I wrote earlier, I have a single-case script that runs a single "case," and a multi-case script that calls the single-case script many times, once for each "case." The multi-case script calls the single-case script without an "&", which makes it a foreground job if I am not mistaken (but of course I am pitifully ignorant of such subtleties). When I saw that something was obviously wrong, and I tried to stop the multi-case script with ctrl-c, I was only stopping the currently running single-case script, then the next single-case script would start running. I just wanted the whole thing to stop running. I added trap 'exit' INT TERM to the multi-case script, and now it seems to stop as is should. I am using RHEL 4 on a Sun Ultra-24. I contend that the "trap" line should not be necessary. It should be the default behavior.
From: Seebs on 3 Jun 2010 21:55 On 2010-06-03, Ben Finney <ben+unix(a)benfinney.id.au> wrote: > In fairness, I'll point out that this isn't readily the case. There are > no books I can find written by ?Seebs?. Perhaps if you used your real > name in your From field, that claim would be true. I'll take "signature block" for 100, Alex. But you have a point. I guess it comes down to "seebs" being my Real Name, and "Peter Seebach" being the thing I have to put on legal forms for historical reasons. -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: Kenny McCormack on 4 Jun 2010 09:45 In article <4220bf0b-91b8-4a3e-875c-eab87a10f031(a)5g2000yqz.googlegroups.com>, Russ P. <russ.paielli(a)gmail.com> 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? It is the default. And you can verify this yourself, by setting up a simpler test bed - i.e., one that doesn't involve rapid process spawning. Clearly, in normal cases, when you press Control/C, the signal is sent to all processes (nitpickers note: No, obviously not *all* processes on the system; I think we all understand what I mean here) and all of those processes exit. Now, I believe that at some point, you reported that adding that line to your script *did* (seem to) fix things. I claim that that is either a reporting error or an inconsistency in the shell (and I'm leaning towards the later). It is quite possible that when you execute that "trap" command, it re-wires something inside the shell - something that should have been set that way in the first place. >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. Yup - you got that right. -- > 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: Jon LaBadie on 4 Jun 2010 14:08
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. My understanding of signals is dated and unix-based. I'm sure someone will jump in to correct any errors in my comments. Signals can be handled in one of three ways, take the default action for that signal, completely ignore the signal, or branch to some function the program(mer) has specified. This is often called "catching" the signal. Note, not all signals have a default of terminate, for example you would not want a parent to die just because it received a signal that a child had died. Nor should a process die just because the alarm clock they set has rung. Each process has a "how am I handling signals" table (at least used to in unix). The entries are 0 for take the default action, 1 for ignore the signal, and any other number is the address of the signal catching function to execute. When you start the process, ignoring any effect from it parents, the signal handling table is full of zeros. The trap call you show above causes the shell to create a function that when called executes the quoted code. So no, "trap 'exit' INT" does not set that signal to its default, it adds the address of a function that simply exits. To return to default handling (adding a 0 to the array) would be "trap '' INT". It may be a subtle difference but they are not the same. For example, across a fork, the signal handling table retains the entries for caught and ignored signals. But upon an exec, the caught signals reset to default (reason? the code they were going to execute no longer exists in the process). Why would you ever want other than default? When you want to perform some action before exiting. Examples include clean up temporary files or child processes, cleanly close connections to databases or other resources, log the event or print a status report, ask the operator if they "really want to quit?", |