Gibberish is printed when invoking msys2_shell.cmd in Build and Run

[ghost]

Command: C:\msys64\msys2_shell.cmd

Arguments: -clang64 -defterm -no-start 'objfw-compile' -o ${current_doc_name} ${current_doc}

You might ask me why I don't use C:\msys64\usr\bin\bash.exe -lcx directly instead. The reason is that doing so the shell script objfw-compile cannot find the clang compiler. This happens even if you manually add C:\msys64\clang64\bin to the Windows PATH.

Here is what it printed:

�[K�[0;33mCompiling �[1;33mC:\Projects\objfw\test\test3.m�[0;33m...�[0m
�[K�[0;32mSuccessfully compiled �[1;32mC:\Projects\objfw\test\test3.m�[0;32m.�[0m
�[K�[0;33mLinking �[1;33mtest3.exe�[0;33m...�[0m
�[K�[0;32mSuccessfully linked �[1;32mtest3.exe�[0;32m.�[0m
The process "C:\msys64\msys2_shell.cmd" exited normally.

I guess they are terminal color codes.

[SpartanJ]

That's terminal output (those are ansi colors), use the terminal 🤷

[SpartanJ]

I'll add an option to use the status bar terminal in the future.

[ghost]

I'll add an option to use the status bar terminal in the future.

Thank you for reminding me about the status bar terminal. It's a good workaround until #651 is implemented.

BTW, what do you mean with this? Using Terminal instead of Build for build output?

[SpartanJ]

Actually I was thinking about the Run step (where I already added the option to "Use status bar terminal", the build step doesn't make much sense, it's very very rare that the build output does not detect if it's within a terminal environment or not (or at least the accept the environment variable NO_COLOR=1 to disable the color output), if I add the option to run the build step in a terminal I think it should always use the status bar terminal, but my main concern is that ecode needs to properly read the output to parse the errors (probably nobody knows but ecode has a customizable build output parser, that by default uses a generic one to find errors and allow the user to jump between the errors from the "Issues" section in the "Build" status bar). I think that the best option is to always clean the ANSI codes (or at least give an option), so we don't need to rely on the terminal for this and keep continue using the Build section.

[ghost]

I had completely forgotten about Output Parser, since it’s tucked away in Advanced Options and I rarely need to go there. But yes, that’s the key here. Instead of running the build step in a terminal, we can process its output using an output parser.

[SpartanJ]

It's now possible to request to strip ansi codes in build and also run. Run option is with the run options checkboxes, and for the build case is in advanced, in Build Environment section.