bash sends SIGHUP to disowned children in non-interactive mode

2011-12-28 Thread ck850
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

Re: bash sends SIGHUP to disowned children in non-interactive mode

2011-12-28 Thread Philip
> 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

Re: bash sends SIGHUP to disowned children in non-interactive mode

2011-12-28 Thread Philip
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

Re: bash sends SIGHUP to disowned children in non-interactive mode

2011-12-28 Thread Chet Ramey
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

Re: bash sends SIGHUP to disowned children in non-interactive mode

2011-12-28 Thread Greg Wooledge
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

Re: bash sends SIGHUP to disowned children in non-interactive mode

2011-12-28 Thread ck850
>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

Re: bash sends SIGHUP to disowned children in non-interactive mode

2011-12-28 Thread Sven Mascheck
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

Re: bash sends SIGHUP to disowned children in non-interactive mode

2011-12-28 Thread Greg Wooledge
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.

bash sends SIGHUP to disowned children in non-interactive mode

2011-12-28 Thread ck850
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

Re: bug in force_interactive handling

2011-12-28 Thread Stas Sergeev
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