Re: Xemacs/cygwin 21.4.3 and new console window during compilation
So my supposition is that a console window is created because XEmacs
doesn't have one by default when started from the desktop. The reason it
works in bash is that children inherit their parent's console by default
and somewhere up the foodchain cygwin has a console. I have no idea how we
could fix this. I imagine that if we do AllocConsole in the cygwin version
of XEmacs that whilst this may stop your program creating a console we will
get an ugly console popping up for XEmacs as a whole. Maybe this is
acceptable, I don't know. I'm CC'ing ben and the cygwin list to see if any
windows gurus have any great ideas on this score.
andy
At 07:56 PM 7/3/2001 +0400, Dmitry Bely wrote:
>I have found very strange thing, which is the real showstopper for me. I
>cannot use ocaml compiler (www.ocaml.org) within Xemacs -- when it's called
>during compilation, new console window is always created and so
>warning/error messages are not catched by XEmacs compilation
>process. Having spent enough time, I've managed to extract from ocaml
>sources the following small test example, that demonstrates the problem:
>
>[---hello.c---]
>#include
>
>int main()
>{
> printf("Hello, world!\n");
> printf("press any key...");
> getchar();
> return 0;
>}
>[---end of hello.c---]
>
>[---hello-run.c---]
>#pragma comment(linker , "/subsystem:console")
>
>#include
>
>#define msg_and_length(msg) msg , (sizeof(msg) - 1)
>const char* app = ".\\hello.exe";
>
>void main()
>{
> STARTUPINFO stinfo;
> PROCESS_INFORMATION procinfo;
> DWORD retcode;
>
> stinfo.cb = sizeof(stinfo);
> stinfo.lpReserved = NULL;
> stinfo.lpDesktop = NULL;
> stinfo.lpTitle = NULL;
> stinfo.dwFlags = 0;
> stinfo.cbReserved2 = 0;
> stinfo.lpReserved2 = NULL;
>
> if (!CreateProcess(app, NULL, NULL, NULL, TRUE, 0, NULL, NULL,
> &stinfo, &procinfo)) {
> HANDLE errh;
> DWORD numwritten;
> errh = GetStdHandle(STD_ERROR_HANDLE);
> WriteFile(errh, msg_and_length("Cannot exec "), &numwritten, NULL);
> WriteFile(errh, app, strlen(app), &numwritten, NULL);
> WriteFile(errh, msg_and_length("\r\n"), &numwritten, NULL);
> ExitProcess(2);
>#if _MSC_VER >= 1200
> __assume(0); /* Not reached */
>#endif
> }
> CloseHandle(procinfo.hThread);
> WaitForSingleObject(procinfo.hProcess , INFINITE);
> GetExitCodeProcess(procinfo.hProcess , &retcode);
> CloseHandle(procinfo.hProcess);
> ExitProcess(retcode);
>#if _MSC_VER >= 1200
> __assume(0); /* Not reached */
>#endif
>}
>[---end of hello-run.c---]
>
>Compile both files with MCVS 6.0:
>
>cl hello.c
>cl hello.run
>
>and run resulting hello-run.exe. If you do it via XEmacs shell/compile
>process, new Win32 console window will popup.
>
>Very doubtful that it's cygwin problem, because if hello-run.exe is
>executed from cygwin's sh or bash, new console is not created.
>
>My configuration:
>XEmacs 21.4.3/cygwin (latest binary distribution)
>Cygwin1.dll 1.3.2-1 (latest binary distribution)
>CYGWIN=tty binmode ntsec
>Windows NT 4.0 sp6a
>MSVC 6.0 sp5
>
>Can you reproduce that? Do you have any idea how it can be fixed?
>
>Hope to hear from you soon,
>Dmitry
--
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: bash/cmd CTRL-C problem...
Chris Faylor wrote: >There is a snapshot up there now which seems to work ok. > >Again, many thanks to Robert Collins for tracking this down. > >Although I said I wasn't overly interested in tracking this down >myself, I was interested in seeing the lessening in email traffic that I >hope this fix engenders. > >I do expect that, when this cygwin DLL is released, there could be a >reaction from another, previously silent camp who relied on the old >CTRL-C behavior. I guess it will be interesting to see if that is the >case. Many thanks for looking at this. While the iron is hot - this problem is still outstanding and I don't know whether you would expect this to be fixed also: Interactive bash shell starts: -> shell script using ash starts: -> java program ^C-ing the script does not have any visible effect (i.e. the java program is not killed). As noted previously this problem is resolved if you make /bin/sh be bash rather than ash. Thanks andy -- 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: Ash spawning win32 programs (was Re: bash/cmd CTRL-C problem...)
At 11:11 PM 1/11/2002 +1100, Robert Collins wrote: >Can I suggest you start a new thread when the topic changes, it helps >prevent confusion - particulary if the original thread hangs around. Sorry. I thought the two might be related. > > Interactive bash shell starts: > > -> shell script using ash starts: > > -> java program > > > > ^C-ing the script does not have any visible effect (i.e. the java >program > > is not killed). As noted previously this problem is resolved if you >make > > /bin/sh be bash rather than ash. > >Hmm. I'll look into this is you will :}. Sure. >I suspect that ash uses vfork rather than fork+exec to start it's child >process's. That may result in no cygwin stub existing. > >here's what you need to do: > >write an ash script that prints out it's pid, and (if you can get it) >the cygwin pid of the java program. > >Start the ash script in the background, and then use ps. See if the java >program appears in ps. If it does - check via task manager or process >explorer to see if the reported cygwin pid is the same as the actual >java.exe pid. > >If it doesn't appear, then no cygwin stub exists, and quite some work >may be needed to *efficiently* create such a virtual process. (it would >be quite trivial via the daemon :}) > >If it does appear, and the shown cygwin pid is the same as the java.exe >pid, then no stub exists, but the bulk of the code to have a 'virtual' >process is there, but signals aren't working correctly. > >If it does appear, and the shown cygwin pid is different than the actual >java.exe pid, then there is a stub, and things should be working >correctly - I'll take a direct look at this point. Ok thanks. I'll see what I can do. andy -- 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: Ash spawning win32 programs (was Re: bash/cmd CTRL-C problem...)
At 11:11 PM 1/11/2002 +1100, Robert Collins wrote: >Start the ash script in the background, and then use ps. See if the java >program appears in ps. If it does - check via task manager or process >explorer to see if the reported cygwin pid is the same as the actual >java.exe pid. > >If it doesn't appear, then no cygwin stub exists, and quite some work >may be needed to *efficiently* create such a virtual process. (it would >be quite trivial via the daemon :}) > >If it does appear, and the shown cygwin pid is the same as the java.exe >pid, then no stub exists, but the bulk of the code to have a 'virtual' >process is there, but signals aren't working correctly. > >If it does appear, and the shown cygwin pid is different than the actual >java.exe pid, then there is a stub, and things should be working >correctly - I'll take a direct look at this point. ash script pid reported by shell: 828 ash script pid in task manager: 856 java pid reported by ps 1640PPID 828 java pid reported by task mnager1640 bash pid1248 BTW with the script started in the background (or indeed fg and ^Z) kill %1 does not work (it used to) it is reported as terminated but is still running. andy -- 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: Ash spawning win32 programs (was Re: bash/cmd CTRL-C problem...)
At 01:22 AM 1/12/2002 +1100, Robert Collins wrote: >- Original Message - >From: "Andy Piper" <[EMAIL PROTECTED]> > > > ash script pid reported by shell: 828 > > ash script pid in task manager: 856 > > java pid reported by ps 1640PPID 828 > > java pid reported by task mnager1640 > > bash pid1248 > >Right, so we've got a win32 process, _with no cygwin stub_. This is a >lot harder to solve than the one Chris and I just solved. The >fundamental difference being that when you CTRL-C in the console window, >every attached program recieves a win32 CTRLC interrupt. Your java >program - by virtue of not quitting - is either deliberately ignoring >those interrupts, or is a gui program with a hidden window. (are you >running javaw or javac?). Its a console app that happily responds to ^C. If you run it directly from within bash then ^C works, so I assume from what you say above that this is a bug of some description. >For console programs, the CTRL-C in the window should work fine. kill >(script) won't work (because no keyboard interrupt is generated). > > > BTW with the script started in the background (or indeed fg and ^Z) >kill %1 > > does not work (it used to) it is reported as terminated but is still >running. > >The script dies quite happily for me. The win32 process doesn't though >(as expected). I guess I don't understand why this is expected. It always used to work (i.e. the subprocess would get killed also). >The key question here is : what semantics should apply to a _non signal >aware program_ when cygwin detects a signal is generated for it? > >I.e., to pick a couple, for SIGINT and SIGKILL. > >One is obvious, we call (IIRC) TerminateProcess and *boom* it's gone. >Hope your work was saved. Er, why isn't it signal aware. It is AFAIK. andy -- 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: Ash spawning win32 programs (was Re: bash/cmd CTRL-C problem...)
At 10:50 AM 1/12/2002 +1100, Robert Collins wrote: >Have you tried the latest snapshot and confirmed that this still occurs? Yes, this is with the latest snapshot. I actually haven't upgraded past 1.3.2 because the problems (like this) get worse from then on (using bash as /bin/sh being the only solution). I'm just trying to suck your brain dry while the issues are still clear in your mind :) > > I guess I don't understand why this is expected. It always used to >work > > (i.e. the subprocess would get killed also). > >It's expected because win32 programs don't understand cygwin signals. >Console programs that appear to understand signals actually get told by >the OS when CTRL-C is hit on the console. So I'm confused. I realise that signals are a cygwin (UNIX) thing but I thought that they were written in such a way as to Do The Right Thing in this instance. Certainly my experience has been that the Right Thing happened at various points in cygwin's history. If you are saying that this is not the right thing anymore then I can accept that but just want to understand why. > > >The key question here is : what semantics should apply to a _non >signal > > >aware program_ when cygwin detects a signal is generated for it? > > > > > >I.e., to pick a couple, for SIGINT and SIGKILL. > > > > > >One is obvious, we call (IIRC) TerminateProcess and *boom* it's gone. > > >Hope your work was saved. > > > > Er, why isn't it signal aware. It is AFAIK. > >I thought this was obvious. Is it linked against cygwin1.dll? No? Then >it's not signal aware. > >Signals are one of the cygwin additions to the win32 platform. Hmn, ok. So shouldn't we just do the same thing as happens under the DOS console? andy -- 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: is anyone able to successfully use make/grep from within xemacs/c ygwin?
That's why I stay on 1.3.2 :) Are you running a pre-built binary? I build the binaries under 1.3.2 - I don't know whether that would make a difference. andy At 12:18 PM 3/13/02 -0800, Taylor, Patrick wrote: >Ever since upgrading from cygwin 1.3.2 (quite a few months ago), >I have had a lot of difficulty with running subprocesses for >make and grep from within xemacs. At first they would fail >only sometimes, but since upgrading to more recent versions of >cygwin, they fail almost every time. > >When I launch a make within xemacs (via M-x compile), the >subprocess almost always hangs. The output buffer shows > > cd /wherever/.../ > make -k > >and that's it. Doing a kill-compilation sometimes has no >effect, and I have to so it several times to actually kill >the subprocess. > >When I launch a grep (via M-x grep), the problem is slightly >different. The subprocess always completes, but often does >not produce any matches in the output buffer even when there >are definitely matches. Sometimes it works fine. > >These problems have severely crippled my development >productivity. I have resorted to running make and grep >from the bash shell outside of xemacs and just manually >processing the errors/matches, losing all the benefits >of running these subprocesses from within xemacs. > >I have searched several mailing lists for cygwin and xemacs >and have found a couple of people with similar problems, but >there have been no followups to those messages, or to the >message I originally posted about this in September. > >My version info: >- XEmacs 21.4 (patch 6) (i686-pc-cygwin) >- Windows 2000 Professional Ver 5.0 Build 2195 Service Pack 2 >- Cygwin DLL version info: > DLL version: 1.3.10 > DLL epoch: 19 > DLL bad signal mask: 19005 > DLL old termios: 5 > DLL malloc env: 28 > API major: 0 > API minor: 51 > Shared data: 3 > DLL identifier: cygwin1 > Mount registry: 2 > Cygnus registry name: Cygnus Solutions > Cygwin registry name: Cygwin > Program options name: Program Options > Cygwin mount registry name: mounts v2 > Cygdrive flags: cygdrive flags > Cygdrive prefix: cygdrive prefix > Cygdrive default prefix: > Build date: Mon Feb 25 11:14:34 EST 2002 > Shared id: cygwin1S3 > >PLEASE: if either >- you know anything about this problem, OR >- you have no problems using the same functionality >LET ME KNOW! > >Please reply to [EMAIL PROTECTED] > >Thanks, >Patrick > >_ >Below is an earlier message about this issue from September. >I received no replies. >_ > >I just upgraded to the latest cygwin DLL version 1.3.3-2. >I'm using Windows 2000 Pro with SP 2. > >I immediately started experiencing problems with subprocesses >in my cygwin version of xemacs (XEmacs 21.4 (patch 3) "Academic >Rigor" [Lucid] (i686-pc-cygwin) of Thu May 17 2001 on SHALOM). > >When I launch a make within xemacs, it often hangs immediately. > >When I launch a grep within xemacs, it always completes but >sometimes finds no matches when there are definitely matches. >Very odd. > >Again, these problems are sporadic, but fairly frequent. >I do not have these problems with make or grep launched directly >from bash. > >Has anyone else experienced this or have a clue what the problem >might be? Please respond by email, since I do not subscribe to >these lists. > >Thanks, >Patrick Taylor >[EMAIL PROTECTED] -- 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/
