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
On 1/4/12 9:50 PM, Chet Ramey wrote:
> On 1/4/12 8:42 AM, Stas Sergeev wrote:
>
>> I just meant for the way to make the trap handler
>> executed when the foreground job is running.
>
> So you'd like the shell to act on a signal without `consulting' the
> foreground job? Take a look at http://www
On 1/4/12 8:42 AM, Stas Sergeev wrote:
> I just meant for the way to make the trap handler
> executed when the foreground job is running.
So you'd like the shell to act on a signal without `consulting' the
foreground job? Take a look at http://www.cons.org/cracauer/sigint.html ,
keeping in mind
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
On 1/4/12 7:20 AM, Stas Sergeev 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
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
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
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
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
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
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 th
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.
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.
> Please check it yourself, her
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
On 12/28/11 4:42 AM, Stas Sergeev wrote:
>>> But, -i sets "interactive_shell" variable, not "interactive", so the
>>> aforementioned comment and code makes no sense, though it
>>> might have been working in the past.
>> `-i' sets the `forced_interactive' variable; look at flags.c. The shell
>> se
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 `expected' means here; both code fragments are
> co
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 `expected' means here; both code fragments are
correct.
> I've found 2 places of the breakage.
>
> 1. initialize_job_control ()
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
19 matches
Mail list logo
