aborting a bash script with control-c
in [Shell]
|
From: Janis Papanagnou on 4 Jun 2010 14:44 Jon LaBadie wrote: > Russ P. wrote: >> [...] > > My understanding of signals is dated and unix-based. I'm sure someone > will jump in to correct any errors in my comments. I will do in one point. :-) > [...] > > 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". trap '' INT will ignore that signal; it's a "catch but do nothing". You're maybe confusing the reset to default with this one trap - INT And certainly this is true for my comment as well... "I'm sure someone will jump in to correct any errors in my comments." Janis
From: Jon LaBadie on 4 Jun 2010 15:01 Janis Papanagnou wrote: > Jon LaBadie wrote: >> Russ P. wrote: >>> [...] >> My understanding of signals is dated and unix-based. I'm sure someone >> will jump in to correct any errors in my comments. > > I will do in one point. :-) > >> [...] >> >> 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". > > trap '' INT > > will ignore that signal; it's a "catch but do nothing". > You're maybe confusing the reset to default with this one > > trap - INT I didn't really type that did I?? Thanks for the correction. > > And certainly this is true for my comment as well... > "I'm sure someone will jump in to correct any errors in my comments." > > Janis
From: Russ P. on 8 Jun 2010 02:14 On Jun 4, 11:08 am, Jon LaBadie <jlaba...(a)aXcXm.org> wrote: > 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?", That's all good to know, and thanks for explaining it. Maybe I missed something, but I still don't understand why exiting is not the default when I hit ctrl-c. Why would I type ctrl-c if I didn't want to exit?
From: Ben Bacarisse on 8 Jun 2010 08:17 "Russ P." <russ.paielli(a)gmail.com> writes: > On Jun 4, 11:08 am, Jon LaBadie <jlaba...(a)aXcXm.org> wrote: <snip> >> 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. This point (which is correct) may be the source of some of the confusion. >> To return to default handling (adding a 0 to the array) would be >> "trap '' INT". I don't think so. It sets the disposition of the signal to "ignored". To return to whatever the default is use: trap SIGINT or trap - SIGINT (i.e. with - or with no function name at all. Note that I prefer SIGxxx signal names since trap uses some other special keywords that are not signals and these names keep the distinction clear.) >> 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?", > > That's all good to know, and thanks for explaining it. Maybe I missed > something, but I still don't understand why exiting is not the default > when I hit ctrl-c. Why would I type ctrl-c if I didn't want to exit? I think you've missed Jon's main point. Terminating the process is the default and I don't think anyone has said anything else. What has been disputed (quite correctly) is that "trap exit SIGINT" is the default. It behaves in a similar way (in many cases) but it is quite different in terms of what it does to the signal table and what it might means all cases. The trap built-in command may well be a red herring. I'd first want to find out why you have a problem at all. I.e. to find out what it is about your scripts that causes them not to terminate. To do that you'd have to say a lot more about what they do -- ideally by cutting them down until you can post an smallish example that exhibits the problem. -- Ben.
From: Martin Vaeth on 8 Jun 2010 15:30
Ben Bacarisse <ben.usenet(a)bsb.me.uk> wrote: > > trap - SIGINT > > [...] Note that I prefer SIGxxx signal names This is not a good idea since it is not POSIX. For example, dash will not understand it. |