05.01.2012 06:50, Chet Ramey wrote:
So you'd like the shell to act on a signal without `consulting' the
foreground job?
For only the dedicated traps. For example:
trap -b /bin/true USR1
-b here would mean that the foreground job, if
any, is to be moved to the background before
executing the com
04.01.2012 17:28, Chet Ramey wrote:
Hello Chet, I double-checked that, and with the attached
quick hack I was able to do:
trap bg USR1
and move the job to the background with just that SIGUSR1.
Do you think such a feature is worth being implemented?
I don't think there's enough need to change bg
03.01.2012 00:07, Chet Ramey wrote:
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 alread
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 on
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 th
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
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
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.
Please check it yourself, here's the script:
---
#!./bash -i
set -m; cat
echo Finished!
while :; do jobs; sleep 2; done
---
Run this script, then do
kill
Hi Chet, thanks for taking a look.
28.12.2011 01:16, Chet Ramey wrote:
> On 12/26/11 10:12 AM, Stas Sergeev wrote:
>> Hi.
>>
>> It seems the -i switch of the bash doesn't work as expected
>> these days (I tried with bash-4.1).
> I'm not sure what `expec
Hi.
It seems the -i switch of the bash doesn't work as expected
these days (I tried with bash-4.1).
I've found 2 places of the breakage.
1. initialize_job_control () has the following code:
---
if (interactive == 0)
{
job_control = 0;
original_pgrp = NO_PID;
shell_tty = fi
10 matches
Mail list logo
