On 12/28/11 5:57 PM, Philip wrote:
> So without job control bash might (I know, we don't know for sure)
> send the SIGHUP to all processes started in the shell, whether child
> by definition or not?
No, it doesn't.
> Shouldn't the -i flag enable job control by the way?
Yes, and it does. The pr
I'm experiencing some strange behaviour with bash and xterm or other
X-terminals.
I'm using bash in Debian stable (GNU bash, Version 4.1.5(1)-release
(i486-pc-linux-gnu)).
To reproduce, write a simple script like this:
#!/bin/bash
(xclock &)
sleep 15
Then run it with xter
> It may receive a SIGHUP, but you haven't demonstrated that it's bash
> sending the SIGHUP. Since job control isn't enabled, it's most likely
> that the SIGHUP xterm sends to the process group when you hit the close
> button gets to xclock because it's in the same process group as bash.
>
> Bash
Am Wed, 28 Dec 2011 14:48:45 -0500
schrieb Greg Wooledge :
>
> If you want to disown something, you have to *stop* doing this double-fork
> nonsense.
>
> #!/bin/bash
> set -m
> xterm &
> disown -h
>
> Do not put (...) around the background job. When you do that, the main
> bash process loses i
On 12/28/11 1:44 PM, ck...@web.de wrote:
>I'm experiencing some strange behaviour with bash and xterm or other
>X-terminals.
>I'm using bash in Debian stable (GNU bash, Version 4.1.5(1)-release
>(i486-pc-linux-gnu)).
>To reproduce this, write a simple script like this:
>#!/b
On Wed, Dec 28, 2011 at 08:37:38PM +0100, ck...@web.de wrote:
>>You could also "disown -h" it and avoid that the signal is sent at
>all.
>>This is especially helpful, if a program resets its signal handlers
>>(e.g. xemacs?).
>What I am saying is, this is not working!
>Please
>You could also "disown -h" it and avoid that the signal is sent at
all.
>This is especially helpful, if a program resets its signal handlers
>(e.g. xemacs?).
What I am saying is, this is not working!
Please try if you can reproduce what I wrote.
If so try to use disown -h. Doe
On Wed, Dec 28, 2011 at 01:47:47PM -0500, Greg Wooledge wrote:
> On Wed, Dec 28, 2011 at 07:44:40PM +0100, ck...@web.de wrote:
> >(xclock &)
>
> >Yet xclock closes when the script exits because it receives a SIGHUP.
>
> If you want a process to ignore a signal, you should either use nohup
On Wed, Dec 28, 2011 at 07:44:40PM +0100, ck...@web.de wrote:
>(xclock &)
>Yet xclock closes when the script exits because it receives a SIGHUP.
If you want a process to ignore a signal, you should either use nohup(1),
or ignore the signal yourself using a trap and then exec it.
I'm experiencing some strange behaviour with bash and xterm or other
X-terminals.
I'm using bash in Debian stable (GNU bash, Version 4.1.5(1)-release
(i486-pc-linux-gnu)).
To reproduce this, write a simple script like this:
#!/bin/bash
(xclock &)
sleep 15
Then run it with
10 matches
Mail list logo
