http://bugs.winehq.org/show_bug.cgi?id=19668
Summary: cmd /c doesn't wait for result before exiting? Product: Wine Version: 1.1.27 Platform: PC OS/Version: Linux Status: NEW Keywords: download, Installer Severity: normal Priority: P2 Component: programs AssignedTo: wine-bugs@winehq.org ReportedBy: dank@kegel.com
The cygwin shell script, http://kegel.com/wine/vc2005x.sh.txt runs properly on Windows Vista and Windows 7, but fails on Wine because the script continues on to the "rm -rf" immediately rather than waiting for Ixpvc.exe to finish, as it does on Windows.
I suspect this is a bug in wine's cmd. Removing the cmd /c prefix from the commandline, to let cygwin's shell run Ixpvc itself, behaves properly, and the following lines aren't run until Ixpvc finishes.
(The only reason the cmd is in the script at all is because it was the only way I could get Ixpvc to run at all on Windows; without it, Windows would report "permission denied", presumably because it thought some bad script was trying to install something.)
http://bugs.winehq.org/show_bug.cgi?id=19668
--- Comment #1 from Dan Kegel dank@kegel.com 2009-08-10 02:02:19 --- Simpler test case: create the batch file bad.bat, containing cmd /c notepad echo foo Then run that with cmd /c bad.bat On Windows, you won't see 'foo' until you quit out of notepad. On Wine, you see it immediately.
http://bugs.winehq.org/show_bug.cgi?id=19668
Dan Kegel dank@kegel.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Component|programs |cmd
http://bugs.winehq.org/show_bug.cgi?id=19668
Jason Edmeades us@edmeades.me.uk changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |us@edmeades.me.uk
--- Comment #2 from Jason Edmeades us@edmeades.me.uk 2010-01-06 18:26:39 --- Adding myself to the cmd bugs
http://bugs.winehq.org/show_bug.cgi?id=19668
--- Comment #3 from Dan Kegel dank@kegel.com 2010-02-05 16:23:33 --- This is happening in the Chromium build. when devenv crashes, I see an old cmd.exe job sitting around, and a new cl.exe job also sitting around (maybe they're both waiting for some lock held by the crashed devenv.exe). I think /MP only affects cl, and devenv otherwise runs one thing at a time, so the fact that devenv is crashing when cmd just happens to have returned too soon suggests that this might be a real problem.
http://bugs.winehq.org/show_bug.cgi?id=19668
--- Comment #4 from Dan Kegel dank@kegel.com 2010-02-05 17:12:16 --- sh build.sh build webcore_bindings_sources probably reproduces the crash. That rule involves devenv running cmd running python running perl running make, or something awful like that.
http://bugs.winehq.org/show_bug.cgi?id=19668
--- Comment #5 from Dan Kegel dank@kegel.com 2010-02-11 11:14:52 --- I guess it's time to write a testcase.
The patch I tried earlier was in wcmdmain.c: - if (assumeInternal || context || !HIWORD(console)) WaitForSingleObject (pe.hProcess, INFINITE); + if (opt_c || opt_k || assumeInternal || context || !HIWORD(console)) WaitForSingleObject (pe.hProcess, INFINITE); but it didn't keep devenv from crashing.
http://bugs.winehq.org/show_bug.cgi?id=19668
Frédéric Delanoy frederic.delanoy@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |frederic.delanoy@gmail.com
--- Comment #6 from Frédéric Delanoy frederic.delanoy@gmail.com 2011-09-07 07:11:38 CDT --- Still in 1.3.27
http://bugs.winehq.org/show_bug.cgi?id=19668
Jason Edmeades us@edmeades.me.uk changed:
What |Removed |Added ---------------------------------------------------------------------------- AssignedTo|wine-bugs@winehq.org |us@edmeades.me.uk
http://bugs.winehq.org/show_bug.cgi?id=19668
--- Comment #7 from Jason Edmeades us@edmeades.me.uk 2012-11-29 17:17:22 CST --- So I spent some time investigating this, and independantly arrived at the conclusion that Dan did with pretty much the same patch - I dont think this is the cause of the devenv crash. A long time ago, there was a problem when cmd.exe launched a Linux compiled app (e.g. notepad) but thats been fixed a while
So to sum up, I tried the following combination, each from a command line
1. Running interactively from command prompt: A- windows app flagged as gui B- windows app flagged as cui C- wines notepad Windows matches wine for A+B, and notepad matches windows GUI, ie. A+C return to command prompt immediately. B waits
2. Running in a batch program, e.g. echo before, testgui, echo done A- windows app flagged as gui B- windows app flagged as cui C- wines notepad Windows matches wine for A+B, and notepad matches windows GUI, ie. all 3 waits for the command to complete
3. Running as cmd /c program A- windows app flagged as gui B- windows app flagged as cui C- wines notepad
This is where the difference lies, and it is specifically because the code assumes that for a GUI application if the context isnt set then we are interactive and hence test scenario 1, which is wrong - If we are part of cmd /c (or /k) then we should do the same as test scenario 3.
Will send patch - no applicable tests will help here
http://bugs.winehq.org/show_bug.cgi?id=19668
--- Comment #8 from Jason Edmeades us@edmeades.me.uk 2012-11-29 17:27:07 CST --- Slightly simpler patch submitted http://www.winehq.org/pipermail/wine-patches/2012-November/120360.html
http://bugs.winehq.org/show_bug.cgi?id=19668
Jason Edmeades us@edmeades.me.uk changed:
What |Removed |Added ---------------------------------------------------------------------------- Fixed by SHA1| |64d7151669faccf09c845112c71 | |a906587629ff7 Status|NEW |RESOLVED Resolution| |FIXED
--- Comment #9 from Jason Edmeades us@edmeades.me.uk 2012-11-30 14:12:50 CST --- Committed
http://bugs.winehq.org/show_bug.cgi?id=19668
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #10 from Alexandre Julliard julliard@winehq.org 2012-12-07 13:36:00 CST --- Closing bugs fixed in 1.5.19.