The newer version of Bash (Maybe after 3.1.6) brings something wrong for the executive operator `(backquote) in Makefile
When execute makefile through make command, any compile line contains the executive operator `(backquote), likes `pkg-config --cflags gtk+-2.0`, would result in a compile error, reported by gcc/g++, which said ": No such file or directory". Any advice would be appreciated. Regards, Zhenghui Zhou -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Why does CYGWIN remap my keys
I sent this message to comp.windows.cygwin but received no reply. I have just installed Cygwin on my Mum's Windows XP Home computer and I noticed that it rebinds some of the keys, such as " -> @ @ -> " \ -> # | -> ~ etc. I managed to patch Gnu Emacs so that it goes back to the old bindings with the following Lisp code: (progn (keyboard-translate 35 92) ;; hash -> backslash (keyboard-translate 126 124) ;; tilde -> vertical bar (keyboard-translate 34 64) ;; doublequote -> ampersand (keyboard-translate 64 34) ;; ampersand -> doublequote (keyboard-translate 163 35) ;; poundsign -> hash (keyboard-translate 172 126) ;; notsign -> tilde ) But a better solution would be to stop CYGWIN from rebinding the keys in the first place, as the Emacs key bindings only work inside Emacs. You could tell me that I should never need to leave Emacs in the first place! However I am running a course in Web Design for high school students so they would probably need the keys to work the way they should in applications such as Internet Explorer or Mozilla Firefox. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: ld: cannot perform PE operations on non PE output file 'bootsect'.
Salvatore D'Angelo wrote: > On Linux it works fine but in cygwin I go the following link problem: > > *ld: cannot perform PE operations on non PE output file 'bootsect'. > > *In the cygwin mail archive I saw question like this without response > please can someone suggest me what is wrong in my Makefile and what I > have to change? That's because 'as' and 'ld' on Linux and Cygwin are not configured for the same default targets. On Linux they create ELF objects, whereas on Cygwin the native format is PE. Whatever tutorial or set of instructions you are following seem to assume an ELF assembler and linker. You might be able to make it work with PE by using objcopy to convert instead of --oformat, along the lines of: ld -Ttext 0x0 -s -o bootsect.tmp bootsect.o && \ objcopy -I pei-386 -O binary bootsect.tmp bootsect && \ rm bootsect.tmp But this will fail if you try to do anything non-trivial that makes use of any kind of ELF assembler directives. Perhaps the better way to proceed would be to build and install a cross-binutils (configure --target=i686-pc-linux) and then use 'i686-pc-linux-as' and 'i686-pc-linux-ld' instead of 'as' and 'ld' and your Makefiles and whatever other tutorials/samples/guides ought to all work exactly as on an ELF system. Brian -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: cannot perform PE operations on non PE output file 'bootsect'.
On 14 November 2006 00:29, Salvatore D'Angelo wrote: > Hi all, > > I have a problem compiling the bootsect.S file above using the Makefile. > Basically the project create a boot sector on floppy that print "Hello > World" at compuer boot. > On Linux it works fine but in cygwin I go the following link problem: > > *ld: cannot perform PE operations on non PE output file 'bootsect'. http://sourceware.org/bugzilla/show_bug.cgi?id=2757 " This is a known problem with the linker. It cannot link PE files and convert to BINARY format at the same time. You will need to link to a PE format file first and then use OBJCOPY to convert it to BINARY format afterwards. " You don't get this on Linux, because Linux uses ELF format object files, not PE, which apparently ld handles fine. The solution is as described: link it first, then use objcopy to extract the text section and convert to binary format. So, you need a link command like: ld -r -Ttext 0x0 -e _start -s -o bootsect.out bootsect.o (we use a relocatable '-r' link because a final link would add the __CTOR_LIST__ and __DTOR_LIST__ data in the text section; a relocatable link will resolve any stray relocs for us without adding those tables), followed by an objcopy like so: objcopy -O binary -j .text bootsect.out bootsect Try the following patch to your makefile: it adds an intermediate linked stage called bootsect.out and then extracts the raw binary boot sector from that. --- Makefile.orig 2006-11-14 01:19:30.214928700 + +++ Makefile2006-11-14 01:19:56.636803700 + @@ -1,11 +1,15 @@ AS=as LD=ld +OBJCOPY=objcopy all: bootsect -bootsect: bootsect.o +bootsect: bootsect.out + @$(OBJCOPY) -O binary -j .text $< $@ + +bootsect.out: bootsect.o @echo "[LD] $@" - @$(LD) -Ttext 0x0 -s --oformat binary -o $@ $< + @$(LD) -Ttext 0x0 -e _start -s -o $@ $< bootsect.o: bootsect.S @echo "[AS] $@" cheers, DaveK -- Can't think of a witty .sigline today Makefile.diff Description: Binary data -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
ld: cannot perform PE operations on non PE output file 'bootsect'.
Hi all, I have a problem compiling the bootsect.S file above using the Makefile. Basically the project create a boot sector on floppy that print "Hello World" at compuer boot. On Linux it works fine but in cygwin I go the following link problem: *ld: cannot perform PE operations on non PE output file 'bootsect'. *In the cygwin mail archive I saw question like this without response please can someone suggest me what is wrong in my Makefile and what I have to change? To build the project do the following steps: 1. download the two file in a directory 2. in cygwin move to this directory 3. type make In linux the final file bootsect should have a size of 512 bytes. Using the command make disk you can copy it on a floppy making it bootable. PS I am not subscribed to this mail list so, please, put my address in cc Thanks in advance for your help. AS=as LD=ld all: bootsect bootsect: bootsect.o @echo "[LD] $@" @$(LD) -Ttext 0x0 -s --oformat binary -o $@ $< bootsect.o: bootsect.S @echo "[AS] $@" @$(AS) -o $@ $< disk: image @echo "[DISK]" @dd if=image of=/dev/fd0 bs=512 image: bootsect @echo "[KERNEL IMAGE]" @cat bootsect > image clean: @echo [CLEAN] @rm -rf *.o image bootsect .code16 .text .global _start _start: movb $0xE, %ah # Function 0x0E of Interrupt 0x10 movb $'H', %al # write 'H' int $0x10 movb $'e', %al # write 'e' int $0x10 movb $'l', %al # write 'l' int $0x10 movb $'l', %al # write 'l' int $0x10 movb $'o', %al # write 'o' int $0x10 movb $' ', %al # write ' ' int $0x10 movb $'W', %al # write 'W' int $0x10 movb $'o', %al # write 'o' int $0x10 movb $'r', %al # write 'r' int $0x10 movb $'l', %al # write 'l' int $0x10 movb $'d', %al # write 'd' int $0x10 movb $'!', %al # write '!' int $0x10 movb $'!', %al # write '!' int $0x10 movb $'!', %al # write '!' int $0x10 ret .org 510# Last 2 bytes of the boot sector. boot_flag: .word 0xAA55# Flag indicating a boot disk -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: w32api/winnt.h BUILD Problem
On 13 November 2006 22:23, Brian Dessent wrote: > In file included from > /usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api/windef.h:246, > from > /usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api/windows.h:48, > from > C:/Eclipse_Workspace/Analyzer_General/ApplIncludes/analyzer/interface/include/ RMAServerImpl.h:4, > from ../analyzer/interface/src/RMAServerImpl.cxx:20: > /usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api/winnt.h: At > global scope: > /usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api/winnt.h:182: > error: expected unqualified-id before ',' token > /usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api/winnt.h:182: > error: extraneous `int' ignored > make: *** [analyzer/interface/src/RMAServerImpl.o] Error 1 > > [ Note: you are using Windows paths and defining WIN32, all of which > implies that you are making a native Windows program. You should be > using MinGW if this is your goal, not Cygwin. But that's not relevant > to your question. ] > > Line 182 of winnt.h is: > > typedef BYTE BOOLEAN,*PBOOLEAN; > > If it's choking on this typedef that means your namespace is polluted, > i.e. some other header or source file has already defined a type or a > macro named BOOLEAN prior to the point where the winnt.h header file is > included. We would need to see your source code (or at the very least > the order of includes) to know anything more. It would also be good to > look at the preprocessed source of the file, which helps debugging macro > namespace issues. You might also be able to use WIN32_LEAN_AND_MEAN to > work around this but I don't recall what exactly it disables. The first thing to do is try rebuilding the file and looking at the preprocessed output. Cut and paste the build command from the log file and add the '--save-temps -dD -E' options, remove the -c, -o and -M options, then look at Analyzer.ii, which should have been created. Find out what line 182 of winnt.h is getting translated to, and then search back up in the file to find out where the #define is coming from. Here's what your command line will need to look like, sorry about how badly wrapped this one is going to get. g++ -D_WIN32_ -D__GNUWIN32__ -DSTRICT -D__WXMSW__ -D__WINDOWS__ -D__WXDEBUG__ -I"C:\Eclipse_Workspace\Analyzer_General\ApplIncludes\analyzer\include" -I"C:\Eclipse_Workspace\Analyzer_General\ApplIncludes\analyzer\interface\inclu de" -I"C:\Eclipse_Workspace\Analyzer_General\ApplIncludes\analyzer\pgeneral\includ e" -I"C:\Eclipse_Workspace\Analyzer_General\ApplIncludes\Pat_Includes" -I"C:\Eclipse_Workspace\TriPac_CDs\TriPac_c_CD\flexlm\v7.2\i86_n3a" -I"C:\Eclipse_Workspace\TriPac_CDs\TriPac_c_CD\flexlm\v7.2\machind" -I"C:\Eclipse_Workspace\Analyzer_General\ApplIncludes\analyzer\general\include " -O0 -g3 -Wall -fmessage-length=0 -fno-rtti -Wno-deprecated -DWIN32 -fexceptions -DWINDOWS -Dw32api --save-temps -dD -E "../analyzer/interface/src/Analyzer.cxx" cheers, DaveK -- Can't think of a witty .sigline today -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: [ANNOUNCEMENT] Updated: bash-3.2.3-5
Eric Blake byu.net> writes:
> Evil. /bin/sh is supposed to be at the same version of bash, if you
> installed
> things correctly. It sounds like your postinstall scripts did not run
> correctly (perhaps you had bash or sh open when you ran setup.exe?). What
> are
> the timestamps on those files ('ls -l /bin/{ba,}sh')?
>
> At any rate, the fix is to rerun the postinstall scripts, or more
> quickly, 'cp /bin/bash /bin/sh'.
Several machines at my site have turned up with the sh vs bash issue above, so I
think something might be amiss with the installation scripts. The workaround of
copying /bin/bash to /bin/sh works of course.
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
Re: w32api/winnt.h BUILD Problem
"Patrick D. McAvoy" wrote: > I am having a problem with BUILDing a fairly large C++ DLL using Cygwin > under Eclipse. I am running Windows XP Media Edition. My Eclipse Project > Name is: Analyzer_General (Build is not an acronym, there's no need to shout.) > My application source code seems to be compiling without errors, but two > errors are reported from the w32api/winnt.h header. > > I have attached the output from cygcheck to this message, as well as the > console log from my BUILD. The full text of the two messages are: > > Description: Path > Resource Location Creation Time Id > /usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api/winnt.h error: > extraneous `int' ignored > Analyzer_Generalline 1821163443618484 652606 > > > /usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api/winnt.h error: > expected unqualified-id before ',' token Analyzer_General > line 1821163443618484 652605 It would be a lot easier if you included the actual g++ command output, not whatever useless mangled version comes from your IDE. From your attachment, that is: In file included from /usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api/windef.h:246, from /usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api/windows.h:48, from C:/Eclipse_Workspace/Analyzer_General/ApplIncludes/analyzer/interface/include/RMAServerImpl.h:4, from ../analyzer/interface/src/RMAServerImpl.cxx:20: /usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api/winnt.h: At global scope: /usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api/winnt.h:182: error: expected unqualified-id before ',' token /usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api/winnt.h:182: error: extraneous `int' ignored make: *** [analyzer/interface/src/RMAServerImpl.o] Error 1 [ Note: you are using Windows paths and defining WIN32, all of which implies that you are making a native Windows program. You should be using MinGW if this is your goal, not Cygwin. But that's not relevant to your question. ] Line 182 of winnt.h is: typedef BYTE BOOLEAN,*PBOOLEAN; If it's choking on this typedef that means your namespace is polluted, i.e. some other header or source file has already defined a type or a macro named BOOLEAN prior to the point where the winnt.h header file is included. We would need to see your source code (or at the very least the order of includes) to know anything more. It would also be good to look at the preprocessed source of the file, which helps debugging macro namespace issues. You might also be able to use WIN32_LEAN_AND_MEAN to work around this but I don't recall what exactly it disables. Brian -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Bash process remains after I close rxvt in certain ways
The problem I've been having for quite a while now may or may not be related to this but it's indeed similar. I start XWin from a batch file that also starts a gnome-terminal. I always have to kill the gnome-pty-helper.exe process in order to be able to open more terminals. The point where it hangs varies from just creating the second terminal to up to maybe the 7th. I've never seen it go beyond that before needing to kill the helper process. This issue made me start a Sysinternals's Process Explorer window as a pre-requisite to starting XWin and the gnome-terminals. I now start XWin and then look in the process explorer window for the gnome-pty-helper process, kill it and then watch the rest of the terminals come up. If I look at the threads in the gnome-pty-helper.exe process, I find two threads, one doing about 92 context switches per second with a start address at 'gnome-pty-helper.exe+0x1000' and the other one is at cygwin1.dll!toascii+0x15d0. This second one is a pretty common address I see when I get cygwin runaway processes using 100% CPU but that's a different story I think (or maybe not?) I've killed that thread only to see if it would help but it looks like something is waiting for the process to finish because things only keep rolling after I kill the process not just the thread. Mind you, sometimes it doesn't happen right away, that is, the second terminal starts find even though the gnome-pty-helper.exe is still there. The other relatead issue is that when I exit the last bash shell in the gnome-terminals, the gnome-terminal.exe process doesn't go away either and I have to kill that one too. Well, actually, Process Explorer says the the gnome-terminal.exe process is a child of a bash.exe process as expected I guess but there are other bash shells, those in each gnome terminal window or tab, which where started by gnome-terminal. They show up as siblings and not as children though. When I kill the gnome-terminal.exe process, the bash.exe parent process goes away by itself. It all seems related to gnome-terminal and the related supporting gnome packages and not to bash itself, which is basically why I haven't posted anything about this here but this time it seems at least somebody might tell me that indeed it's not and point in a more hopeful direction. Thanks -- Luis P Caamano Atlanta, GA USA On 13 Nov 2006 15:08:48 -, [EMAIL PROTECTED] Igor Peshansky wrote: > According to Eric Lilja on 11/12/2006 12:52 PM: > > I recently upgraded to a dual core machine which made me use the windows > > task manager alot. That's when I noticed that if I close the rxvt window > > by pressing 'x' in the top right corner (or doing alt-f4, I never do > > this, just tried it now to see what happened) the rxvt process is > > terminated and the window disappears but the "underlying" bash process > > is still running (without a visible window), consuming ~3.5 MB of memory > > and 0 cpu time according to the task manager. > > So far, no one has found a good way for a cygwin process killed by Alt-F4 > (or the X button) to treat that as a SIGHUP and pass that information on > to all of its children processes. So, by killing rxvt abruptly, you are > indeed stranding bash as a zombie process. > > > If I exit rxvt by typing > > exit, the bash process is terminated too. > > Actually, typing exit will exit bash, not rxvt; but when rxvt realizes > that all of its children processes have exited, it exits as well. > > > Can I do something so the bash > > process is always terminated properly no matter how I close the rxvt > > window? > > Submit a patch to make cygwin processes recognize Alt-F4 as a SIGHUP that > needs to be passed to their children? Or possibly even a patch such that > when a controlling pty terminal is closed, all children (such as bash) > reading from that pty get an end-of-input (possibly a SIGPIPE) when trying > to read from the disappearing terminal? Actually, it's not the Cygwin processes that need that feature, but the W11 library. When rxvt is closed via the 'X' button or Alt-F4, Windows sends it the WM_QUIT message, which ought to be handled properly in the library as application exit (and thus send SIGHUP to all immediate children). This is done by the Cygwin console already, so it may simply be a matter of copying/pasting some code... > > Is there misconfiguration on my end or should I simply get in > > the habit of always using exit to close rxvt? > > For now, that is the best course of action. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Bash process remains after I close rxvt in certain ways
On Mon, Nov 13, 2006 at 03:18:56PM +, Eric Blake wrote: >Charles Wilson cwilson.fastmail.fm> writes: > >> Or what *should* be happening. >> >> So, I think that in src/command.c, right before exit() is called, rxvt >> ought to kill its children -- except I thought exit() should do that >> already? > >http://www.opengroup.org/onlinepubs/009695399/functions/exit.html: >"Termination of a process does not directly terminate its children. The >sending >of a SIGHUP signal as described below indirectly terminates children in some >circumstances. >... >"If the process is a controlling process, the SIGHUP signal shall be sent to >each process in the foreground process group of the controlling terminal >belonging to the calling process. >"If the process is a controlling process, the controlling terminal associated >with the session shall be disassociated from the session, allowing it to be >acquired by a new controlling process. >"If the exit of the process causes a process group to become orphaned, and if >any member of the newly-orphaned process group is stopped, then a SIGHUP >signal >followed by a SIGCONT signal shall be sent to each process in the newly- >orphaned process group." > >Sounds like you are right - rxvt should be a controlling process, so calling >exit() should automatically cause cygwin to send SIGHUP to the process group, >and rxvt shouldn't have to do any manual killing. This is handled in dcrt0.cc:do_exit(). I'm wondering if rxvt is not dealing with the SIGHUP that cygwin should be sending to it on CTRL_CLOSE, though. cgf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Problem with C app compiled under cygwin on win32
> > Did you copy the version you compiled on Windows NT (hence 32-bit and > would use WOW)? Or did you recompile it on x64? If you recompiled > it, what compiler did you use and what options? (show command-line and > output from "gcc -v", but using your compiler if not just "gcc") I used the version compiled on Windows NT. It is 32-bit and I believe it is using WOW since there's a "*32" besides the application name. It should work, no? I have posted on comp.lang.c (http://tinyurl.com/yg4zy8) but I'm not sure why that fixes it when the behaviour of the application should be the same since it uses WOW? Patrick -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Bash process remains after I close rxvt in certain ways
Charles Wilson cwilson.fastmail.fm> writes: > Or what *should* be happening. > > So, I think that in src/command.c, right before exit() is called, rxvt > ought to kill its children -- except I thought exit() should do that > already? http://www.opengroup.org/onlinepubs/009695399/functions/exit.html: "Termination of a process does not directly terminate its children. The sending of a SIGHUP signal as described below indirectly terminates children in some circumstances. ... "If the process is a controlling process, the SIGHUP signal shall be sent to each process in the foreground process group of the controlling terminal belonging to the calling process. "If the process is a controlling process, the controlling terminal associated with the session shall be disassociated from the session, allowing it to be acquired by a new controlling process. "If the exit of the process causes a process group to become orphaned, and if any member of the newly-orphaned process group is stopped, then a SIGHUP signal followed by a SIGCONT signal shall be sent to each process in the newly- orphaned process group." Sounds like you are right - rxvt should be a controlling process, so calling exit() should automatically cause cygwin to send SIGHUP to the process group, and rxvt shouldn't have to do any manual killing. -- Eric Blake -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Bash process remains after I close rxvt in certain ways
Eric Blake wrote: So far, no one has found a good way for a cygwin process killed by Alt-F4 (or the X button) to treat that as a SIGHUP and pass that information on to all of its children processes. So, by killing rxvt abruptly, you are indeed stranding bash as a zombie process. Actually, I think rxvt/W11 already handles some of this; in W11/w32/event.c, MSWin messages WM_DESTROY, WM_QUIT, and WM_CLOSE ... case WM_DESTROY: case WM_QUIT: case WM_CLOSE: event->type = ClientMessage; event->xclient.format = 32; event->xclient.data.l[0] = XInternAtom(NULL,"WM_DELETE_WINDOW", FALSE); break; ... are all turned into an X11-style XA_WMDELETEWINDOW message, which is then handled (in src/command.c) by case ClientMessage: if (ev->xclient.format == 32 && (Atom)ev->xclient.data.l[0] == h->xa[XA_WMDELETEWINDOW]) exit(EXIT_SUCCESS); (There is a little translation between the string "WM_DELETE_WINDOW", the struct h->xa, and the enum which defines XA_WMDELETEWINDOW, but that's basically what happens). Or what *should* be happening. So, I think that in src/command.c, right before exit() is called, rxvt ought to kill its children -- except I thought exit() should do that already? -- Chuck -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Bash process remains after I close rxvt in certain ways
On Mon, Nov 13, 2006 at 08:15:15AM -0500, Igor Peshansky wrote: >On Mon, 13 Nov 2006, Eric Blake wrote: > >> According to Eric Lilja on 11/12/2006 12:52 PM: >> > I recently upgraded to a dual core machine which made me use the windows >> > task manager alot. That's when I noticed that if I close the rxvt window >> > by pressing 'x' in the top right corner (or doing alt-f4, I never do >> > this, just tried it now to see what happened) the rxvt process is >> > terminated and the window disappears but the "underlying" bash process >> > is still running (without a visible window), consuming ~3.5 MB of memory >> > and 0 cpu time according to the task manager. >> >> So far, no one has found a good way for a cygwin process killed by Alt-F4 >> (or the X button) to treat that as a SIGHUP and pass that information on >> to all of its children processes. So, by killing rxvt abruptly, you are >> indeed stranding bash as a zombie process. >> >> > If I exit rxvt by typing >> > exit, the bash process is terminated too. >> >> Actually, typing exit will exit bash, not rxvt; but when rxvt realizes >> that all of its children processes have exited, it exits as well. >> >> > Can I do something so the bash >> > process is always terminated properly no matter how I close the rxvt >> > window? >> >> Submit a patch to make cygwin processes recognize Alt-F4 as a SIGHUP that >> needs to be passed to their children? Or possibly even a patch such that >> when a controlling pty terminal is closed, all children (such as bash) >> reading from that pty get an end-of-input (possibly a SIGPIPE) when trying >> to read from the disappearing terminal? > >Actually, it's not the Cygwin processes that need that feature, but the >W11 library. When rxvt is closed via the 'X' button or Alt-F4, Windows >sends it the WM_QUIT message, which ought to be handled properly in the >library as application exit (and thus send SIGHUP to all immediate >children). This is done by the Cygwin console already, so it may simply >be a matter of copying/pasting some code... Actually, Cygwin sends a SIGHUP to the process being closed when it sees a CTRL_CLOSE_EVENT. Maybe it just needs to send a SIGHUP to the entire process group rather than just the one process. I'll look into that. cgf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Bash process remains after I close rxvt in certain ways
On Mon, 13 Nov 2006, Eric Blake wrote: > According to Eric Lilja on 11/12/2006 12:52 PM: > > I recently upgraded to a dual core machine which made me use the windows > > task manager alot. That's when I noticed that if I close the rxvt window > > by pressing 'x' in the top right corner (or doing alt-f4, I never do > > this, just tried it now to see what happened) the rxvt process is > > terminated and the window disappears but the "underlying" bash process > > is still running (without a visible window), consuming ~3.5 MB of memory > > and 0 cpu time according to the task manager. > > So far, no one has found a good way for a cygwin process killed by Alt-F4 > (or the X button) to treat that as a SIGHUP and pass that information on > to all of its children processes. So, by killing rxvt abruptly, you are > indeed stranding bash as a zombie process. > > > If I exit rxvt by typing > > exit, the bash process is terminated too. > > Actually, typing exit will exit bash, not rxvt; but when rxvt realizes > that all of its children processes have exited, it exits as well. > > > Can I do something so the bash > > process is always terminated properly no matter how I close the rxvt > > window? > > Submit a patch to make cygwin processes recognize Alt-F4 as a SIGHUP that > needs to be passed to their children? Or possibly even a patch such that > when a controlling pty terminal is closed, all children (such as bash) > reading from that pty get an end-of-input (possibly a SIGPIPE) when trying > to read from the disappearing terminal? Actually, it's not the Cygwin processes that need that feature, but the W11 library. When rxvt is closed via the 'X' button or Alt-F4, Windows sends it the WM_QUIT message, which ought to be handled properly in the library as application exit (and thus send SIGHUP to all immediate children). This is done by the Cygwin console already, so it may simply be a matter of copying/pasting some code... > > Is there misconfiguration on my end or should I simply get in > > the habit of always using exit to close rxvt? > > For now, that is the best course of action. If you don't want to go looking at the guts of the W11 library, yes. Igor -- http://cs.nyu.edu/~pechtcha/ |\ _,,,---,,_[EMAIL PROTECTED] | [EMAIL PROTECTED] ZZZzz /,`.-'`'-. ;-;;,_Igor Peshansky, Ph.D. (name changed!) |,4- ) )-,_. ,\ ( `'-' old name: Igor Pechtchanski '---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow! "Las! je suis sot... -Mais non, tu ne l'es pas, puisque tu t'en rends compte." "But no -- you are no fool; you call yourself a fool, there's proof enough in that!" -- Rostand, "Cyrano de Bergerac" -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Bash process remains after I close rxvt in certain ways
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Eric Lilja on 11/12/2006 12:52 PM: > I recently upgraded to a dual core machine which made me use the windows > task manager alot. That's when I noticed that if I close the rxvt window > by pressing 'x' in the top right corner (or doing alt-f4, I never do > this, just tried it now to see what happened) the rxvt process is > terminated and the window disappears but the "underlying" bash process > is still running (without a visible window), consuming ~3.5 MB of memory > and 0 cpu time according to the task manager. So far, no one has found a good way for a cygwin process killed by Alt-F4 (or the X button) to treat that as a SIGHUP and pass that information on to all of its children processes. So, by killing rxvt abruptly, you are indeed stranding bash as a zombie process. > If I exit rxvt by typing > exit, the bash process is terminated too. Actually, typing exit will exit bash, not rxvt; but when rxvt realizes that all of its children processes have exited, it exits as well. > Can I do something so the bash > process is always terminated properly no matter how I close the rxvt > window? Submit a patch to make cygwin processes recognize Alt-F4 as a SIGHUP that needs to be passed to their children? Or possibly even a patch such that when a controlling pty terminal is closed, all children (such as bash) reading from that pty get an end-of-input (possibly a SIGPIPE) when trying to read from the disappearing terminal? > Is there misconfiguration on my end or should I simply get in > the habit of always using exit to close rxvt? For now, that is the best course of action. - -- Life is short - so eat dessert first! Eric Blake [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFWGwp84KuGfSFAYARAhoLAJ4mOFhGOWHcWVFqT1TUminyFF2/3wCgkWST Ibeyo2qq9zIyLaopU7CY3rM= =5ncP -END PGP SIGNATURE- -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Bash process remains after I close rxvt in certain ways
Eric Lilja wrote: [snip] > Ok, no replies yet. I understand if people don't have the > solution/explanation at hand, but maybe someone else could try my rxvt > shortcut and say if he or she is seeing the same problem as I am? Yes, I can see the same problem if I close the window using the button. And the bash process stays waiting for input: $ ps PIDPPIDPGID WINPID TTY UIDSTIME COMMAND ... I 832 1 832 23842 1006 03:29:53 /usr/bin/bash -- René Berber -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Bash process remains after I close rxvt in certain ways
Eric Lilja skrev: Hello, I never open the default cygwin "command window" anymore. Instead I use rxvt (a program I was introduced to after using cygwin for more than a year and I immediately fell in love with it). In my quicklaunch bar I have the following rxvt shortcut: C:\cygwin\bin\rxvt.exe -tn rxvt-cygwin-native -sr -sl 4000 -fn "Lucida Console-13" --background black --foreground white -geometry 145x40+10+0 -e bash --login -I I recently upgraded to a dual core machine which made me use the windows task manager alot. That's when I noticed that if I close the rxvt window by pressing 'x' in the top right corner (or doing alt-f4, I never do this, just tried it now to see what happened) the rxvt process is terminated and the window disappears but the "underlying" bash process is still running (without a visible window), consuming ~3.5 MB of memory and 0 cpu time according to the task manager. If I exit rxvt by typing exit, the bash process is terminated too. Can I do something so the bash process is always terminated properly no matter how I close the rxvt window? Is there misconfiguration on my end or should I simply get in the habit of always using exit to close rxvt? cygcheck.out attached. / E Ok, no replies yet. I understand if people don't have the solution/explanation at hand, but maybe someone else could try my rxvt shortcut and say if he or she is seeing the same problem as I am? / E Cygwin Configuration Diagnostics Current System Time: Sun Nov 12 20:39:19 2006 Windows XP Professional Ver 5.1 Build 2600 Service Pack 2 Path: C:\cygwin\usr\local\bin C:\cygwin\bin C:\cygwin\bin C:\cygwin\usr\X11R6\bin c:\WINDOWS\system32 c:\WINDOWS c:\WINDOWS\System32\Wbem c:\mingw32-make-3.81-1\bin c:\Program Files\IDM Computer Solutions\UltraEdit-32 c:\emacs\bin c:\Program Files\ATI Technologies\ATI.ACE\ c:\Program Files\Common Files\Teleca Shared Output from C:\cygwin\bin\id.exe (nontsec) UID: 1003(hivemind) GID: 513(None) 0(root) 513(None) 544(Administrators) 545(Users) Output from C:\cygwin\bin\id.exe (ntsec) UID: 1003(hivemind) GID: 513(None) 0(root) 513(None) 544(Administrators) 545(Users) SysDir: C:\WINDOWS\system32 WinDir: C:\WINDOWS USER = 'hivemind' PWD = '/home/hivemind' HOME = '/home/hivemind' MAKE_MODE = 'unix' HOMEPATH = '\Documents and Settings\hivemind' MANPATH = '/usr/local/man:/usr/share/man:/usr/man::/usr/ssl/man' APPDATA = 'C:\Documents and Settings\hivemind\Application Data' HOSTNAME = 'mindcooler' TERM = 'rxvt-cygwin-native' PROCESSOR_IDENTIFIER = 'x86 Family 15 Model 43 Stepping 1, AuthenticAMD' WINDIR = 'C:\WINDOWS' VS80COMNTOOLS = 'C:\vs8\Common7\Tools\' WINDOWID = '6830152' OLDPWD = '/usr/bin' USERDOMAIN = 'MINDCOOLER' OS = 'Windows_NT' ALLUSERSPROFILE = 'C:\Documents and Settings\All Users' DEFAULT_CA_NR = 'CA6' !:: = '::\' TEMP = '/cygdrive/c/DOCUME~1/hivemind/LOCALS~1/Temp' COMMONPROGRAMFILES = 'C:\Program Files\Common Files' USERNAME = 'hivemind' PROCESSOR_LEVEL = '15' FP_NO_HOST_CHECK = 'NO' SYSTEMDRIVE = 'C:' USERPROFILE = 'C:\Documents and Settings\hivemind' CLIENTNAME = 'Console' PS1 = '\[\e]0;[EMAIL PROTECTED] \[\e[33m\]\w\[\e[0m\]\n\$ ' LOGONSERVER = '\\MINDCOOLER' PROCESSOR_ARCHITECTURE = 'x86' SHLVL = '1' COLORFGBG = '15;default;0' PATHEXT = '.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH' HOMEDRIVE = 'C:' COMSPEC = 'C:\WINDOWS\system32\cmd.exe' TMP = '/cygdrive/c/DOCUME~1/hivemind/LOCALS~1/Temp' SYSTEMROOT = 'C:\WINDOWS' CVS_RSH = '/bin/ssh' PROCESSOR_REVISION = '2b01' INFOPATH = '/usr/local/info:/usr/share/info:/usr/info:' PROGRAMFILES = 'C:\Program Files' DISPLAY = ':0' NUMBER_OF_PROCESSORS = '2' SESSIONNAME = 'Console' COMPUTERNAME = 'MINDCOOLER' COLORTERM = 'rxvt-xpm' _ = '/usr/bin/cygcheck' POSIXLY_CORRECT = '1' HKEY_CURRENT_USER\Software\Cygnus Solutions HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin\mounts v2 HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin\Program Options HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2 (default) = '/cygdrive' cygdrive flags = 0x0022 HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/ (default) = 'C:\cygwin' flags = 0x000a HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/usr/bin (default) = 'C:\cygwin/bin' flags = 0x000a HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/usr/lib (default) = 'C:\cygwin/lib' flags = 0x000a HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\Program Options c: hd NTFS 8Mb 41% CP CS UN PA FC d: cd CDFS 654Mb 100%CS UN CIV4WARLORDS C:\cygwin / system binmode C:\cygwin/bin /us
