https://bugs.winehq.org/show_bug.cgi?id=57804
Bug ID: 57804 Summary: cmd: CALL instruction freezes Product: Wine Version: 10.0 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: major Priority: P2 Component: cmd Assignee: wine-bugs@winehq.org Reporter: Dominik-Home@gmx.de Distribution: ---
Executing the 'CALL'-instruction on a *.bat file may causes freezes when using e.g. '@echo off' in the called script.
```console $ wine --version wine-10.0 (Staging) ```
I inserted two minimal reproducers below that are used in the following examples. Note that I marked the output of the scripts as comment with the REM command as well as my own descriptions.
```cmd C:>C:\working.bat REM C:>echo Test REM Test REM Command returns immediately. No issue here
C:>C:\issue.bat REM Test REM Command returns immediately. No issue here
C:>CALL C:\working.bat REM C:>echo Test REM Test REM Command returns immediately. No issue here
C:>CALL C:\issue.bat REM Test REM ISSUE: Command freezes here and never returns ```
working.bat: ```cmd @echo on
echo Test ```
issue.bat: ```cmd @echo off
echo Test ```
This issue was encountered while trying out PlanAhead, a tool included in the Xilinx ISE design package. They use multiple batch scripts to configure the environment before starting the GUI application. Because the batch files do not work properly the GUI does not start at all. I.e. the application (PlanAhead) is completely unusable.
https://bugs.winehq.org/show_bug.cgi?id=57804
mata sutupud@yahoo.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |sutupud@yahoo.com
--- Comment #1 from mata sutupud@yahoo.com --- From what I can see it *does* return, it just seems to hang because "echo" stays off.
You can verify that by adding `@echo on` to the end of your batch file.
So the issue would be that the terminal prompt is not enabled after calling a batch file (if that's the behaviour on windows, I didn't check...)
https://bugs.winehq.org/show_bug.cgi?id=57804
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |download, testcase
https://bugs.winehq.org/show_bug.cgi?id=57804
--- Comment #2 from Dominik-Home@gmx.de --- I see and confirm the behaviour you're describing. Windows is showing the prompt after calling issue.bat, i.e. there is still a bug present in Wine but under the changed circumstances it's not that critical anymore.
I'm going to change the title and priority of this issue report.
For reference, this issue is not the root cause why PlanAhead does not start, I have to investigate a bit further to find the actual issue.
https://bugs.winehq.org/show_bug.cgi?id=57804
Dominik-Home@gmx.de changed:
What |Removed |Added ---------------------------------------------------------------------------- Summary|cmd: CALL instruction |cmd: '@echo off' gets |freezes |propagated to parent on | |CALL instruction (CALL | |seems to freezes) Severity|major |trivial
https://bugs.winehq.org/show_bug.cgi?id=57804
Eric Pouech eric.pouech@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |eric.pouech@gmail.com
--- Comment #3 from Eric Pouech eric.pouech@gmail.com --- Created attachment 78016 --> https://bugs.winehq.org/attachment.cgi?id=78016 tentative patch
this patch shall likely solve the ticket (didn't test it does, but should from the description)
https://bugs.winehq.org/show_bug.cgi?id=57804
--- Comment #4 from Eric Pouech eric.pouech@gmail.com --- did a bit more testings, and situation seems a bit more complex
it looks like the restoration of the echo mode only happens when invoking a .bat from the command prompt but not when a .bat calls into another .bat can you confirm that all your testings were done from cmd prompt and calling into a .bat file (which does @echo off)
TIA
https://bugs.winehq.org/show_bug.cgi?id=57804
--- Comment #5 from Dominik-Home@gmx.de --- Thanks for taking a look into this so fast. I haven't had time to compile wine myself and apply this patch yet.
But I confirm that all my testing was done from the cmd prompt and not "CALL"ing from one bat-script into another.
https://bugs.winehq.org/show_bug.cgi?id=57804
--- Comment #6 from Dominik-Home@gmx.de --- Your observation seems to be right, Microsoft documented this behavior:
If used in a batch file, echo on and echo off don't affect the setting at the command prompt. [1]
[1] https://learn.microsoft.com/en-us/windows-server/administration/windows-comm...
https://bugs.winehq.org/show_bug.cgi?id=57804
--- Comment #7 from Eric Pouech eric.pouech@gmail.com --- submitted https://gitlab.winehq.org/wine/wine/-/merge_requests/7301 that shall fix this issue (among other things)
https://bugs.winehq.org/show_bug.cgi?id=57804
Eric Pouech eric.pouech@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Fixed by SHA1| |2d2c661c6ccf2c1bc93ecfa6088 | |628ccad93cb5d Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED
--- Comment #8 from Eric Pouech eric.pouech@gmail.com --- resolved fixed
https://bugs.winehq.org/show_bug.cgi?id=57804
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #9 from Alexandre Julliard julliard@winehq.org --- Closing bugs fixed in 10.2.
https://bugs.winehq.org/show_bug.cgi?id=57804
--- Comment #10 from Dominik-Home@gmx.de --- I'm confirming the fix in 10.2. Thank you very much!
-
WineHQ Bugzilla