Actually, this is something I'd like to understand better.
|
| Author | Content |
|---|---|
| BernardSwiss Jun 15, 2012 8:07 PM EDT |
It seems to me that once upon a time, I was able to do something like this just by backgrounding the task eg: $ "xload & " However, for quite some while I have found that this works for some things, but not for others: $ "xterm & " while $ "xload & " but if I put $ "xload & " $ "gkrellm & " (And launching xload or gkrellm from the Alt-F2 run command dialouge also works) Does anybody have a good link for an explanation of this matter? (PS: "disown" appears to be a bash-builtin) |
| mbaehrlxer Jun 15, 2012 10:00 PM EDT |
without verifying, i believe it works like this: when the terminal closes, the program inside receives a signal, that it can either catch and react to or not. greetings, eMBee. (removed incorrect and unclear statements) |
| gus3 Jun 15, 2012 10:05 PM EDT |
It's a matter of catching forwarded signals. When you close gnome-terminal, its shell's child processes get SIGTERM's. Just like when you press Ctrl-C, the shell sends a SIGINT to the foreground child process. "xeyes" doesn't ignore SIGTERM; "xterm" and "gkrellm" do. That's why "xeyes &" will go away when you close gnome-terminal, but "xterm &" and "gkrellm &" continue running. But, if you "disown %N", then that job is removed from the shell's list of child processes, so the shell is no longer concerned with sending them signals. That's a function of the shell. Clear as mud? |
| BernardSwiss Jun 15, 2012 11:04 PM EDT |
Sorry Gus3, I see my post somehow dropped a piece when I posted it (yeah that's it, it was the post that screwed up -- it couldn't have been me) I've edited the original post to insert that line. But yes, I followed your explanation. It matches this bit from the bash-builtins man page
disown [-ar] [-h] [jobspec ...]
Without options, each jobspec is removed from the table of active
jobs. If jobspec is not present, and neither -a nor -r is sup-
plied, the shell's notion of the current job is used. If the -h
option is given, each jobspec is not removed from the table, but is
marked so that SIGHUP is not sent to the job if the shell receives
a SIGHUP. If no jobspec is present, and neither the -a nor the -r
option is supplied, the current job is used. If no jobspec is sup-
plied, the -a option means to remove or mark all jobs; the -r
option without a jobspec argument restricts operation to running
jobs. The return value is 0 unless a jobspec does not specify a
valid job.But I was looking for a little more, and a little less dryly technical. For example, is xterm compiled to ignore SIGHUP? |
| gus3 Jun 15, 2012 11:21 PM EDT |
According to /proc/(pid)/status on my machine, xterm ignores SIGHUP (signal 1) and SIGTTOU (signal 22). I see no patches in my source repo, so I assume that means it's that way by design. EDIT: Look for the line starting with "SigIgn". The hex bits that are set are the ignored signals, but the LSB is bit 1, not bit 0. |
| BernardSwiss Jun 15, 2012 11:26 PM EDT |
I would never have thought of looking in /proc for anything like that |
| jezuch Jun 16, 2012 3:36 AM EDT |
nohup? |
| jezuch Jun 16, 2012 3:37 AM EDT |
And screen, of course :) |
| gus3 Jun 16, 2012 6:50 AM EDT |
nohup uses the same principle as xterm and gkrellm: ignore the signal (SIGHUP here), then exec(). You can see the pertinent kernel call with the following command:
strace nohup cat /dev/null screen is a horse of a different hex triplet. |
| BernardSwiss Jun 16, 2012 7:02 PM EDT |
Cool! I remembered nohup, but mis-remembered it as a GNU option ( --no-hup ), or perhaps that's just for particular commands. And I presume that "insulating" a command in a script works because as far as Bash shell is concerned, the script completed (returned a "command succeeded" signal)? |
| gus3 Jun 16, 2012 9:21 PM EDT |
Not sure what you mean by "insulation," but the background invocation (with the ampersand) succeeds if the command is found and executed. If it isn't found, or can't be executed (say, with -rw-rw-rw- permissions), it returns a non-zero status. In either case, execution continues in the command stream. If a background job returns to the foreground, through "fg" or with the "%N" (percent-N) notation, its exit status will be reflected normally in $?. If you have several jobs in the background, and you "wait" for them, essentially putting them all in the foreground at once, the command's exit status is success. If you "wait %N1 %N2 %N3" for them, the wait command's exit status is the status of %N3. That is, if I'm reading correctly the man page for bash. |
Posting in this forum is limited to members of the group: [ForumMods, SITEADMINS, MEMBERS.]
Becoming a member of LXer is easy and free. Join Us!