# Bug in swipl DOS-Shell of Parallels Desktop of SWI Prolog version 8.3.9 **URL:** \ **Category:** Help!\ **Tags:** bug\ **Created:** [October 12, 2020, 12:11pm UTC](https://swi-prolog.discourse.group/t/bug-in-swipl-dos-shell-of-parallels-desktop-of-swi-prolog-version-8-3-9/3034 "2020-10-12T12:11:16Z")\ **Posts on this page:** 5\ **Page:** 1
**Author:** ![Iam](https://avatars.discourse-cdn.com/v4/letter/i/58956e/32.png) [@Iam](https://swi-prolog.discourse.group/u/Iam)\ **Post date:** [October 12, 2020, 12:11pm UTC](https://swi-prolog.discourse.group/t/bug-in-swipl-dos-shell-of-parallels-desktop-of-swi-prolog-version-8-3-9/3034/1 "2020-10-12T12:11:16Z")
I’m using: SWI-Prolog version 8.3.9 in a DOS-Shell of [Parallels Desktop](https://www.parallels.com/) When I call swipl in a DOS shell, after the execution of a certain goal (e.g. 3=3) or after calling an undefined procedure, the interpreter switches into a broken state. Once the interpreter is in this broken state, 1. color is changed to background color (black in my case) 2. when typing in more goals, I do not see my input anymore. 3. answers for some goals (e.g. 4=4) are shown, but answers to other goals (e.g. X is 6) are nor shown 4. error messages for calling goals of undefined predicates are still shown. 5. Terminating the interpreter with typing in “halt.” seems to work in the sense that further commands cannot be entered, but it does not return to the DOS shell prompt. But: Typing in other goals (e.g. X is 3+4) does not switch the interpreter to go into broken state. The same command sequence works well when executing it in the interpreter called by swipl\bin\swipl.exe and it also works well with version 8.3.9 in a MacOS terminal shell. ---
**Author:** ![jan](https://yyz2.discourse-cdn.com/free1/user_avatar/swi-prolog.discourse.group/jan/32/4_2.png) [@jan](https://swi-prolog.discourse.group/u/jan)\ **Post date:** [October 12, 2020, 12:40pm UTC](https://swi-prolog.discourse.group/t/bug-in-swipl-dos-shell-of-parallels-desktop-of-swi-prolog-version-8-3-9/3034/2 "2020-10-12T12:40:09Z")
Looks like it may get confused by Prolog’s attempt to manage the colors? Does it work under the standard cmd.exe? You could try ``` ?- set_prolog_flag(color_term, false). ``` ---
**Author:** ![Iam](https://avatars.discourse-cdn.com/v4/letter/i/58956e/32.png) [@Iam](https://swi-prolog.discourse.group/u/Iam)\ **Post date:** [October 12, 2020, 1:09pm UTC](https://swi-prolog.discourse.group/t/bug-in-swipl-dos-shell-of-parallels-desktop-of-swi-prolog-version-8-3-9/3034/3 "2020-10-12T13:09:14Z")
> [@jan](#): > > `set_prolog_flag(color_term, false).` Yes, turning into error state happens under the standard CMD.exe . However, if ```prolog ?- set_prolog_flag(color_term, false). ``` is the first command in the interpreter, everything works as intended. Thank you very much! It looks like this command has to be typed in before the interpreter has switched to error state. Once, the interpreter is in error state, this command does not help anymore. I want to use SWI-Prolog in a AI class with students that have not yet used Prolog, and I want to avoid that students have to install SWI-Prolog a second time. What is the best way to deal with this error? Go back to stable version or something else? ---
**Author:** ![jan](https://yyz2.discourse-cdn.com/free1/user_avatar/swi-prolog.discourse.group/jan/32/4_2.png) [@jan](https://swi-prolog.discourse.group/u/jan)\ **Post date:** [October 12, 2020, 1:16pm UTC](https://swi-prolog.discourse.group/t/bug-in-swipl-dos-shell-of-parallels-desktop-of-swi-prolog-version-8-3-9/3034/4 "2020-10-12T13:16:55Z")
The stable version probably has the same issue as nothing was changed to this stuff for a very long time. Apparently Parallels Desktop doesn’t implement the same console API as cmd.exe. I do not consider that a Prolog bug. Why not have the students use swipl-win.exe? That also provides menus, the graphical debugger, etc. The console mode is pretty crude and I wouldn’t use it for anything interactive. Normally you can add disabling color to your init file, but that will be a hard job to communicate as well. ---
**Author:** ![Iam](https://avatars.discourse-cdn.com/v4/letter/i/58956e/32.png) [@Iam](https://swi-prolog.discourse.group/u/Iam)\ **Post date:** [October 12, 2020, 6:50pm UTC](https://swi-prolog.discourse.group/t/bug-in-swipl-dos-shell-of-parallels-desktop-of-swi-prolog-version-8-3-9/3034/5 "2020-10-12T18:50:48Z")
Jan, thank you very much for your fast response! This was very helpful for me. I have another (may be related) problem: I have a 2 lines Prolog file ```prolog :- writeln('program started') . main :- writeln('done'). ``` called test.pl . When I try to compile this program in the CMD.exe shell provided under Parallels Desktop, it compiles correctly ```prolog > swipl --goal=main -o test39.exe -c test.pl program started % Disabled autoloading (loaded 27 files) % Disabled autoloading (loaded 2 files) % Disabled autoloading (loaded 0 files) However, here the shell hangs, i.e., I can not stop the process using ^C, I can only close the CMD.exe window ``` The executable is produced correctly and is runnable. Nevertheless, I could be more productive, if the shell would not hang. However, if I change my test program to ```prolog :- writeln('program started') . main :- undefined_procedure . ``` the compilation process generates an executable as before and blocks after compilation as before. But now running the executable in a new window produces not only the desired error message, i.e. ```prolog ERROR: -g user:main: Unknown procedure: undefined_procedure/0 ERROR: In: ERROR: [10] undefined_procedure ERROR: [8] catch(user:main,error(existence_error(procedure,...),context(...,_2582)),'$toplevel':true) at c:/program files/swipl8.3.9/boot/init.pl:528 ERROR: [7] catch_with_backtrace(user:main,error(existence_error(procedure,...),context(...,_2646)),'$toplevel':true) at c:/program files/swipl8.3.9/boot/init.pl:578 ERROR: ERROR: Note: some frames are missing due to last-call optimization. ERROR: Re-run your program in debug mode (:- debug.) to get more detail. ``` but the process also blocks afterwards, i.e., ^C does not stop the process, and I have to close the CMD.exe window , and must open a new CMD.exe window before I can run the test again. For both, for the compilation step and for the execution step, I would prefer a solution that does not block the CMD.exe window if an error occurs, i.e., where I could return to the CMD.exe shell and continue testing. Is there an easy way out? I appreciate any advice.