From: Kenny McCormack on
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
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
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
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
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?",