Re: cygwin/1.3.20-1 bash child process disassociation behavior weirdness
> Resent-To: [EMAIL PROTECTED] > Resent-From: [EMAIL PROTECTED] > Mailing-List: contact [EMAIL PROTECTED]; run by ezmlm > Sender: [EMAIL PROTECTED] > Mail-Followup-To: [EMAIL PROTECTED] > X-Injected-Via-Gmane: http://gmane.org/ > From: Thorsten Kampe <[EMAIL PROTECTED]> > Date: Tue, 11 Mar 2003 23:43:23 +0100 [snip] > > * Francis Litterio (03-03-11 21:03 +0100) > > Max Bowsher wrote: > >> Richard H. Broberg wrote: > >>> In the meantime I'll > >>> happily use rxvt in place of bash, since it does what I need. > >> > >> You are confused. > >> > >> rxvt is a terminal. > >> bash is a shell. > > > > Looked at another way: > > > >rxvt is a GUI application. > >bash is a console application. > > Not necessarily. Quoting Igor Pechtchanski: "Cygwin rxvt can run > without X using the W11 library it comes with." - and I think this is > how most people use it under Cygwin. > > Richard H. Broberg was quite confused: rxvt is a terminal runnig a > shell like bash running applications. > No, I wasn't; in this context I was referring to bash as in "using the 'bash cygwin shell' shortcut, aka 'bash --login -i'", which results in a window appearing (yes, it happens to be a console window). Running rxvt also causes a window to appear, either on an X DISPLAY or as a standalone window. Running programs in the background in the 'bash --login -i' window results in the behavior I described. The end result is that I cannot spawn a bash shell (with --login -i) which results in a window, put a program nohup in the background, and exit the window (well, I can, but the window sticks around until the child process is gone). And I can do just that in rxvt. Pedantry and semantics aside, I did some investigation with AllocConsole and FreeConsole. Although it seems as though these may be a necessary component of fixing the problem, it doesn't seem sufficient. I wrote a test program which called 'FreeConsole' after it logged something (so I could be sure it properly ran!), then blocked for 60 seconds. Running this in a bash window (bash --login -i, aka 'cygwin bash shell') nohup, input/output redirected, and backgrounded, still didn't let me exit bash (without blocking). So even providing that some magic was done at fork/exec in bash, or in exit() in the library (to ensure 'console' releasing) I think it needs more. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: cygwin/1.3.20-1 bash child process disassociation behavior weirdness
* Francis Litterio (03-03-11 21:03 +0100) > Max Bowsher wrote: >> Richard H. Broberg wrote: >>> In the meantime I'll >>> happily use rxvt in place of bash, since it does what I need. >> >> You are confused. >> >> rxvt is a terminal. >> bash is a shell. > > Looked at another way: > > rxvt is a GUI application. > bash is a console application. Not necessarily. Quoting Igor Pechtchanski: "Cygwin rxvt can run without X using the W11 library it comes with." - and I think this is how most people use it under Cygwin. Richard H. Broberg was quite confused: rxvt is a terminal runnig a shell like bash running applications. Windows | cygwin1.dll Console/rxvt | bash/zsh/tcsh/pdksh | Midnight Commander/vim Thorsten -- Content-Type: text/explicit; charset=ISO-8859-666 (Parental Advisory) Content-Transfer-Warning: message contains innuendos not suited for children under the age of 18 -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: cygwin/1.3.20-1 bash child process disassociation behavior weirdness
> Resent-To: [EMAIL PROTECTED] > Resent-From: [EMAIL PROTECTED] > From: "Max Bowsher" <[EMAIL PROTECTED]> [snip] > > Richard H. Broberg wrote: > > In the meantime I'll > > happily use rxvt in place of bash, since it does what I need. > > You are confused. > > rxvt is a terminal. > bash is a shell. > pedantically, you are correct. when I refer to 'bash' in this context, I'm referring to bash --login -i which gives me a window which the bash shell is running in. I know that the problem isn't completely in bash proper by itself, as my test of running 'nohup sleep 60 &' in a bash shell started started in a cmd.exe shell doesn't block when bash exits, but does block when the cmd.exe shell tries to exit. > You are very likely running bash in rxvt. > > Max. > > correct, no '-e' overrides going on. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: cygwin/1.3.20-1 bash child process disassociation behavior weirdness
Richard H. Broberg wrote: > In the meantime I'll > happily use rxvt in place of bash, since it does what I need. You are confused. rxvt is a terminal. bash is a shell. You are very likely running bash in rxvt. Max. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: cygwin/1.3.20-1 bash child process disassociation behavior weirdness
> Resent-To: [EMAIL PROTECTED] > Resent-From: [EMAIL PROTECTED] > From: "Max Bowsher" <[EMAIL PROTECTED]> > Date: Sat, 8 Mar 2003 01:17:25 - [snip] > > Richard H. Broberg wrote: > >> From: "Max Bowsher" <[EMAIL PROTECTED]> > >> > >> An unfortunate consequence of how Windows handles console windows. > >> > >> I believe it would be possible to write an alternative > >> implementation of nohup using fork/setsid, or perhaps even hack > >> some changes into the Cygwin DLL. > >> But it's now just a configuration issue - it will take some coding. > >> > > > > hmm...I feared as much. Can you give me details on 'of how Windows > > handles console windows'? > > Not specifically. I have a pretty good idea where I'd go looking to find > out, but I don't have the information at my fingertips. > > (I'd look at the MSDN AllocConsole/FreeConsole docs, and follow links from > there) > > > Surely it's not > > impossible; the windows' command 'start' basically 'does the right > > thing', and the semantics of 'start' are basically no different than > > 'nohup command &'. > > I've a feeling start will still open a console window. > > > When you say 'console windows' do you mean > > 'console linked app', as in the /SUBSYSTEM:CONSOLE silliness in > > win32 link-land? > > No, I mean the window Windows provides to run such apps in. > hmm, and yet after seeing responses to this list that rxvt works (which I verified for myself), I am compelled to believe that this isn't the whole story. The fact that rxvt works (without special builtin hackery) makes me think that bash should be able to as well. If the problem is truly the windows 'window' behavior (which I'm not convinced it is either, see my 'look how the windows "start" command works in a window), then why not have bash be in a window more like rxvt instead of more like cmd.exe? These are only suggestions at this point, of course, until I roll up my sleeves to address the problem for real. In the meantime I'll happily use rxvt in place of bash, since it does what I need. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: cygwin/1.3.20-1 bash child process disassociation behavior weirdness
Please keep replies on the list. Richard H. Broberg wrote: >> From: "Max Bowsher" <[EMAIL PROTECTED]> >> >> An unfortunate consequence of how Windows handles console windows. >> >> I believe it would be possible to write an alternative >> implementation of nohup using fork/setsid, or perhaps even hack >> some changes into the Cygwin DLL. >> But it's now just a configuration issue - it will take some coding. >> > > hmm...I feared as much. Can you give me details on 'of how Windows > handles console windows'? Not specifically. I have a pretty good idea where I'd go looking to find out, but I don't have the information at my fingertips. (I'd look at the MSDN AllocConsole/FreeConsole docs, and follow links from there) > Surely it's not > impossible; the windows' command 'start' basically 'does the right > thing', and the semantics of 'start' are basically no different than > 'nohup command &'. I've a feeling start will still open a console window. > When you say 'console windows' do you mean > 'console linked app', as in the /SUBSYSTEM:CONSOLE silliness in > win32 link-land? No, I mean the window Windows provides to run such apps in. Max. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: cygwin/1.3.20-1 bash child process disassociation behavior weirdness
* Richard H. Broberg (03-03-07 22:47 +0100) > In non-cygwin unix I'm familiar with being able to do the following in a > shell (bash or other): > > $ nohup long-running-command & > $ exit > > and be able to leave it running. > > However, under cygwin (this has been true for at least back to cygwin/1.3.6 > for me), when I start a process in the background and try to exit > my bash shell, it hangs until the child process completes (almost as > if it's doing a wait() on its children). > > Additionally, if I start a command nohup in the background in 1 bash shell > and close the window, it kills the child process. > > The easiest way to test this is: > > in 1 window: > > $ sleep 60 & > $ exit > logout > > (parent process (shell window) will not exit until after the child process > is complete, 60 seconds later) > > Also, this doesn't seem to be limited to bash; I get the same behavior > in tcsh. > > Is there something I need to do to cause bash to properly disassociate itself > from child processes so that I get get commands to run in the background > and leave my shell? Use rxvt. Thorsten -- Content-Type: text/explicit; charset=ISO-8859-666 (Parental Advisory) Content-Transfer-Warning: message contains innuendos not suited for children under the age of 18 -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: cygwin/1.3.20-1 bash child process disassociation behavior weirdness
Christopher Faylor wrote: > On Fri, Mar 07, 2003 at 06:17:17PM -0500, Igor Pechtchanski wrote: >> On Fri, 7 Mar 2003, Max Bowsher wrote: >>> Christopher Faylor wrote: This works for me: nohup sleep 30 foo 2>&1& at least with the latest version of cygwin... >>> >>> Doesn't work for me, running self-built cvs HEAD cygwin dll. >>> >>> By doesn't work, I mean: >>> I copy-paste the exact command above >>> I Ctrl-D >>> Bash exits, but the comsole window remains for 30 seconds. >> >> Could be a CYGWIN=tty issue... > > I tried it both ways. Odd. Works for me without tty, fails with tty. [EMAIL PROTECTED] [~] $ uname -svr CYGWIN_NT-5.1 1.3.21(0.77/3/2) 2003-03-07 19:52 Max. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: cygwin/1.3.20-1 bash child process disassociation behavior weirdness
On Fri, Mar 07, 2003 at 06:17:17PM -0500, Igor Pechtchanski wrote: >On Fri, 7 Mar 2003, Max Bowsher wrote: >> Christopher Faylor wrote: >> > On Fri, Mar 07, [EMAIL PROTECTED]:00:28PM -, Max Bowsher wrote: >> >> Richard H. Broberg wrote: >> >>> In non-cygwin unix I'm familiar with being able to do the following >> >>> in a shell (bash or other): >> >>> >> >>> $ nohup long-running-command & >> >>> $ exit >> >>> >> >>> and be able to leave it running. >> >>> >> >>> However, under cygwin (this has been true [EMAIL PROTECTED] back to >> >>> cygwin/1.3.6 for me), when I start a process in the background and >> >>> try to exit >> >>> my bash shell, it hangs until the child process completes (almost as >> >>> if it's doing a wait() on its children). >> >>> >> >>> Additionally, if I start a command nohup in the background in 1 bash >> >>> shell and close the window, it kills the child process. >> >> >> >> An unfortunate consequence of how Windows handles console windows. >> > >> > This works for me: >> > >> > nohup sleep 30 foo 2>&1& >> > >> > at least with the latest version of cygwin... >> >> Doesn't work for me, running self-built cvs HEAD cygwin dll. >> >> By doesn't work, I mean: >> I copy-paste the exact command above >> I Ctrl-D >> Bash exits, but the comsole window remains for 30 seconds. > >Could be a CYGWIN=tty issue... I tried it both ways. cgf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: cygwin/1.3.20-1 bash child process disassociation behavior weirdness
On Fri, 7 Mar 2003, Max Bowsher wrote: > Christopher Faylor wrote: > > On Fri, Mar 07, [EMAIL PROTECTED]:00:28PM -, Max Bowsher wrote: > >> Richard H. Broberg wrote: > >>> In non-cygwin unix I'm familiar with being able to do the following > >>> in a shell (bash or other): > >>> > >>> $ nohup long-running-command & > >>> $ exit > >>> > >>> and be able to leave it running. > >>> > >>> However, under cygwin (this has been true [EMAIL PROTECTED] back to > >>> cygwin/1.3.6 for me), when I start a process in the background and > >>> try to exit > >>> my bash shell, it hangs until the child process completes (almost as > >>> if it's doing a wait() on its children). > >>> > >>> Additionally, if I start a command nohup in the background in 1 bash > >>> shell and close the window, it kills the child process. > >> > >> An unfortunate consequence of how Windows handles console windows. > > > > This works for me: > > > > nohup sleep 30 foo 2>&1& > > > > at least with the latest version of cygwin... > > Doesn't work for me, running self-built cvs HEAD cygwin dll. > > By doesn't work, I mean: > I copy-paste the exact command above > I Ctrl-D > Bash exits, but the comsole window remains for 30 seconds. > > Max. Could be a CYGWIN=tty issue... Igor -- http://cs.nyu.edu/~pechtcha/ |\ _,,,---,,_[EMAIL PROTECTED] ZZZzz /,`.-'`'-. ;-;;,_[EMAIL PROTECTED] |,4- ) )-,_. ,\ ( `'-' Igor Pechtchanski '---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow! Oh, boy, virtual memory! Now I'm gonna make myself a really *big* RAMdisk! -- /usr/games/fortune -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: cygwin/1.3.20-1 bash child process disassociation behavior weirdness
Works for me using rxvt. "Richard H. Broberg" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > > In non-cygwin unix I'm familiar with being able to do the following in a > shell (bash or other): > > $ nohup long-running-command & > $ exit > > and be able to leave it running. > > However, under cygwin (this has been true for at least back to cygwin/1.3.6 > for me), when I start a process in the background and try to exit > my bash shell, it hangs until the child process completes (almost as > if it's doing a wait() on its children). > > Additionally, if I start a command nohup in the background in 1 bash shell > and close the window, it kills the child process. > > The easiest way to test this is: > > in 1 window: > > $ sleep 60 & > $ exit > logout > > (parent process (shell window) will not exit until after the child process > is complete, 60 seconds later) > > Also, this doesn't seem to be limited to bash; I get the same behavior > in tcsh. > > Is there something I need to do to cause bash to properly disassociate itself > from child processes so that I get get commands to run in the background > and leave my shell? > -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: cygwin/1.3.20-1 bash child process disassociation behavior weirdness
Works for me using rxvt. "Richard H. Broberg" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > > In non-cygwin unix I'm familiar with being able to do the following in a > shell (bash or other): > > $ nohup long-running-command & > $ exit > > and be able to leave it running. > > However, under cygwin (this has been true for at least back to cygwin/1.3.6 > for me), when I start a process in the background and try to exit > my bash shell, it hangs until the child process completes (almost as > if it's doing a wait() on its children). > > Additionally, if I start a command nohup in the background in 1 bash shell > and close the window, it kills the child process. > > The easiest way to test this is: > > in 1 window: > > $ sleep 60 & > $ exit > logout > > (parent process (shell window) will not exit until after the child process > is complete, 60 seconds later) > > Also, this doesn't seem to be limited to bash; I get the same behavior > in tcsh. > > Is there something I need to do to cause bash to properly disassociate itself > from child processes so that I get get commands to run in the background > and leave my shell? > -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: cygwin/1.3.20-1 bash child process disassociation behavior weirdness
Christopher Faylor wrote: > On Fri, Mar 07, 2003 at 10:00:28PM -, Max Bowsher wrote: >> Richard H. Broberg wrote: >>> In non-cygwin unix I'm familiar with being able to do the following >>> in a shell (bash or other): >>> >>> $ nohup long-running-command & >>> $ exit >>> >>> and be able to leave it running. >>> >>> However, under cygwin (this has been true for at least back to >>> cygwin/1.3.6 for me), when I start a process in the background and >>> try to exit >>> my bash shell, it hangs until the child process completes (almost as >>> if it's doing a wait() on its children). >>> >>> Additionally, if I start a command nohup in the background in 1 bash >>> shell and close the window, it kills the child process. >> >> An unfortunate consequence of how Windows handles console windows. > > This works for me: > > nohup sleep 30 foo 2>&1& > > at least with the latest version of cygwin... Doesn't work for me, running self-built cvs HEAD cygwin dll. By doesn't work, I mean: I copy-paste the exact command above I Ctrl-D Bash exits, but the comsole window remains for 30 seconds. Max. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: cygwin/1.3.20-1 bash child process disassociation behavior weirdness
On Fri, Mar 07, 2003 at 10:00:28PM -, Max Bowsher wrote: >Richard H. Broberg wrote: >> In non-cygwin unix I'm familiar with being able to do the following >> in a shell (bash or other): >> >> $ nohup long-running-command & >> $ exit >> >> and be able to leave it running. >> >> However, under cygwin (this has been true for at least back to >> cygwin/1.3.6 for me), when I start a process in the background and >> try to exit >> my bash shell, it hangs until the child process completes (almost as >> if it's doing a wait() on its children). >> >> Additionally, if I start a command nohup in the background in 1 bash >> shell and close the window, it kills the child process. > >An unfortunate consequence of how Windows handles console windows. This works for me: nohup sleep 30 foo 2>&1& at least with the latest version of cygwin... cgf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: cygwin/1.3.20-1 bash child process disassociation behavior weirdness
Richard H. Broberg wrote: > In non-cygwin unix I'm familiar with being able to do the following > in a shell (bash or other): > > $ nohup long-running-command & > $ exit > > and be able to leave it running. > > However, under cygwin (this has been true for at least back to > cygwin/1.3.6 for me), when I start a process in the background and > try to exit > my bash shell, it hangs until the child process completes (almost as > if it's doing a wait() on its children). > > Additionally, if I start a command nohup in the background in 1 bash > shell and close the window, it kills the child process. An unfortunate consequence of how Windows handles console windows. I believe it would be possible to write an alternative implementation of nohup using fork/setsid, or perhaps even hack some changes into the Cygwin DLL. But it's now just a configuration issue - it will take some coding. Max. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
