Calls to hg in V1.8 will break the execution of a batch file in Windows. Even a simple batch file that outputs the version number will break. In the following .cmd file the last echo is never displayed. echo park hg version echo lake None of my batch files work any more because execution stops after the hg call.
I just noticed the same thing. I suspect the reason for this is that the "hg" command (at least the one supplied with TortoiseHg) is actually a .cmd (renamed .bat) file, and for some inane reason, the default behavior in Windows is that when a batch file is called from another, it simply takes over, and never returns to the previous batch file. I don't know if there is any way to override this behavior from the batch file being called, but one solution is to add "call" before each "hg" command in the main batch file. That will make it return when the called batch file exits.
Repro here too; also noticing some **very** odd results with stream redirections - i.e. it looks like hg is taking over stdout is some deep way and not releasing it. For example, I had: @hg identify -i -r tip >> somefile Initially nothing after this line ran; moving this line into a separate bat (using CALL), and all **subsequent** output from later lines (that should go to stdout) ended up in somefile. Very, very bad juju
Adding sborho. We definitely can't switch from .exe to .cmd due to the "call" issue.
Here's the history: py2exe does not support -b1 on x64, meaning it cannot bundle DLL and PYD files into the library.zip. So your choices are to add a half-dozen DLLs to the %PATH% and pray they don't interfere with other applications, or ship batch files that hide the mess. Since we started shipping x64 installers, I've done the latter. See also issue 2658. Note that there's nothing to prevent users from adding the root install folder into their patch and ignoring the batch files. There's still exe files there. With thg the dll count is about two dozen, once you add the svn SWIG bindings, pywin32, and Qt. After two years of maintaining the GTK version of thg, I'm quite gun-shy on this issue. But I think much of the pain there was caused by GTK itself.
Ok, so this isn't actually a regression as this never worked with the x64 package. Reducing to bug as several workarounds apparently exist. We should consider using something like: http://effbot.org/zone/exemaker.htm to avoid the whole py2exe and cmd script disaster and get something that works more or less like the Linux version.
I tried ExeMaker and it was quite limited, it looks like development stopped in 2004. It essentially didn't support anything more complicated than a single script file. But I've decided to ditch the bin/ folder for the next release; I had four bugs raised in one week in my bug tracker for various things this changed or broke, and two here. I've pushed the change to the thg repo already; I'll push one for the Mercurial standalone MSI packages to crew-stable probably tomorrow.
--- Bug imported by bugzilla@serpentine.com 2012-05-12 09:17 EDT --- This bug was previously known as _bug_ 2673 at http://mercurial.selenic.com/bts/issue2673 Imported an attachment (id=1530)
this was fixed before 1.9