Re: bug in force_interactive handling
02.01.2012 07:15, Chet Ramey wrote: On 12/30/11 5:36 AM, Stas Sergeev wrote: Hello Chet, thanks for your patch file. It is slightly broken, attached is the fixed version of your patch. BUT: it solves only half of the bug. Thanks, I inadvertently left that part of the patch out of what I sent. Will you apply this patch for the next bash release? Do you know how to fix also this? If you send the `cat' a SIGCONT it will end up running in the background: its process group id will never be the same as the terminal's. Sending SIGCONT from another process will not set the terminal's process group to cat's pgid. That's why things like `fg' and `bg' are shell builtins -- so the shell can multiplex the terminal's process group among its children. Thanks for the explanation. In this case it would be nice for bash to have a signal that will move the background process to the foreground. Without this I still can't do what I intended: I wanted the script to finish, leaving the background process running. This works only if my script sleeps till I send SIGCONT to the process. If it doesn't sleep, the SIGCONT may arrive later than the script finishes, and the job gets killed. I wonder if its possible in bash to implement the signal handler to move the process to the background, but that's probably about asking too much. :) Thanks for your help!
Re: bug in force_interactive handling
On 1/2/12 4:27 AM, Stas Sergeev wrote: > 02.01.2012 07:15, Chet Ramey wrote: >> Thanks, I inadvertently left that part of the patch out of what I sent. > Will you apply this patch for the next bash release? Yes, it's already applied. > In this case it would be nice for bash to have > a signal that will move the background process > to the foreground. But there is already a command to do that: fg. You can hook SIGCHLD with a trap handler, process the `jobs' output, and fg the appropriate process. I still think that's way more work than you need to do. > Without this I still can't do > what I intended: I wanted the script to finish, > leaving the background process running. This > works only if my script sleeps till I send SIGCONT > to the process. Since you're not really using job control at all, but controlling the process's status by sending it signals from another process, you could add a process in between, making the job you're interested in a grandchild of the shell. That way it doesn't matter what the shell does when it exits. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
Re: bug in force_interactive handling
02.01.2012 22:27, Chet Ramey wrote: In this case it would be nice for bash to have a signal that will move the background process to the foreground. But there is already a command to do that: fg. Sorry, mistyped, I meant the other way around: move the foreground process to the background, then finish the script, leaving the process alive. Will your suggestion about the trap handler work also for ^Z+bg rather than just fg? could add a process in between, making the job you're interested in The extra process in-between is a good workaround, yes, but I wonder if this can be avoided.
Re: bug in force_interactive handling
On 1/2/12 1:38 PM, Stas Sergeev wrote: > 02.01.2012 22:27, Chet Ramey wrote: >>> In this case it would be nice for bash to have >>> a signal that will move the background process >>> to the foreground. >> But there is already a command to do that: fg. > Sorry, mistyped, I meant the other way around: move > the foreground process to the background, then finish > the script, leaving the process alive. The SIGSTOP/SIGCONT works to put the process into the background: the jobs pgrp is not the same as the terminal's pgrp. If you don't want the shell to terminate the job at exit because it's stopped, use `disown' after the job stops to have the shell forget it while you continue it from another process. > Will your suggestion about the trap handler work > also for ^Z+bg rather than just fg? It should. I know that `cat' was just an example, but you have to make sure the job you want to stop/continue is not attempting to read from the terminal. If it is, the kernel will SIGTSTP it every time. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
Re: bug in force_interactive handling
02.01.2012 22:53, Chet Ramey wrote: the script, leaving the process alive. The SIGSTOP/SIGCONT works to put the process into the background: the jobs pgrp is not the same as the terminal's pgrp. If you don't want the shell to terminate the job at exit because it's stopped, use `disown' after the job stops to have the shell forget it while you continue it from another process. Thanks! The disown might do the trick. Will your suggestion about the trap handler work also for ^Z+bg rather than just fg? It should. I tried: --- trap bg USR1 --- Now if I first send SIGSTOP to the job and then SIGUSR1 to bash, that works. Is it possible to avoid sending SIGSTOP to the job, and make the trap handler to do both things at once? Not that it is strictly required since you already described a few other ways, but I wonder. :)
Re: bug in force_interactive handling
On 1/2/12 2:10 PM, Stas Sergeev wrote: >>> Will your suggestion about the trap handler work >>> also for ^Z+bg rather than just fg? >> It should. > I tried: > --- > trap bg USR1 > --- > Now if I first send SIGSTOP to the job and then SIGUSR1 to > bash, that works. > Is it possible to avoid sending SIGSTOP to the job, and make > the trap handler to do both things at once? Not that it is strictly > required since you already described a few other ways, but I wonder. :) Well, this is getting pretty esoteric. On one hand, you can avoid the entire SIGSTOP/SIGCONT issue by initially starting the job in the background with `&'. On the other, if you want to move a foreground job to the background, you have to get it to give up control somehow, and sending it a signal is the way to do that. You can install a trap handler for another signal, say SIGALRM, and have some process send SIGALRM to the shell after some period (e.g., `( sleep 20 ; kill -ALRM $$)' ), but you'll have to get the shell to react to the signal once it's received rather than waiting for the foreground process to change state. Once you get the shell running, it can issue the SIGSTOP/bg. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
Re: bug in force_interactive handling
03.01.2012 00:07, Chet Ramey wrote: background with `&'. On the other, if you want to move a foreground job to the background, you have to get it to give up control somehow, and sending it a signal is the way to do that. Unless I am mistaken, nothing special is required for that, and SIGSTOP only makes waitpid() to return, but any other signal can be used to interrupt waitpid() with EINTR. But, in case of EINTR, bash simply restarts waitpid() it seems. So my wild guess is that the functionality of moving the process to the background can be implemented with some special type of trap that will not restart waitpid() after that signal is received. But anyway, I already have the workable solutions to this. :)
