[PR #1394] Console: Fix problems when using CLI from MSYS2/GitBash/ConEmu #495

New Issue

claunia · 2026-01-29T19:08:10Z

claunia commented

2026-01-29 19:08:10 +00:00

Original Pull Request: https://github.com/stenzek/duckstation/pull/1394

State: closed
Merged: Yes

what it does

Fix issue where console output is lost when running from MSYS2/GitBash CLI
Fix issue where pipe redirections would be overridden and output would always go to the attached console (this affected windows cmd prompt as well as other shell CLIs)
Simplifies some logic regarding registering of the standard output writer
A best-effort is made to honor any pre-existing pipe redirections which may have been specified by user or an invoking process.

test cases

run from GitBash/mintty and observe that help printed to the terminal:

$ duckstation -help

run from explorer/Visual Studio and observe that console window is allocated when Console is enabled.

remarks about standard outputs

I renamed some of the ConsoleOutput functions to StandardOutput, though only ones static to the scope of log.cpp for now. The terminology clarity can be helpful. The Console is very much a Microsoft Windows (MSW) term and is rarely used outside of the Windows ecosystem. Better terms are as follows:

Terminal (TTY) : this defines a window or socket/device that can receive Standard Output and provide Standard Input
Shell (Command Processor) : this defines an application that can receive Standard Input and execute commands, scripts, etc. and usually ensures any processes it creates have their standard pipes attached to the terminal (unless redirected).

When you combine a Terminal with a Shell, you get an interactive Command Prompt we all know. You can run shells without the terminal, and you can run terminals without a shell. Windows Console is a terminal without a shell. Windows Terminal (the new UWP replacement for Console available on the Windows App Store) is also a terminal without a shell.

Anyway, whether it's a terminal or console isn't important. What is important is that it's writing to "standard output" -- this is a construct that can, at the discretion of the invoking user or process, be either:

a terminal/console
a redirection to a file
a redirection to another process
a redirection to a socket or FIFO that can then be read asynchronously by other shells and processes (my favorite!)

This was all part of the rationale for me renaming 'ConsoleOutput' to 'StandardOutput'

`WIN32` vs. `_WIN32`

I used _WIN32 to identify the Windows SDK platform. I consider the define preferable as it's a first-class buildsystem define, similar to _MSC_VER / __clang__ / __ANDROID__, etc. and such. By comparison, WIN32 must be manually specified by the makefile/vcxproj. In many newer project templates, I've seen the define missing entirely. My recommendation is to migrate all your instances of WIN32 to _WIN32 at some point.

**Original Pull Request:** https://github.com/stenzek/duckstation/pull/1394 **State:** closed **Merged:** Yes --- ## what it does - Fix issue where console output is lost when running from MSYS2/GitBash CLI - Fix issue where pipe redirections would be overridden and output would always go to the attached console (this affected windows cmd prompt as well as other shell CLIs) - Simplifies some logic regarding registering of the standard output writer - A best-effort is made to honor any pre-existing pipe redirections which may have been specified by user or an invoking process. ## test cases - run from GitBash/mintty and observe that help printed to the terminal: ``` $ duckstation -help ``` - run from explorer/Visual Studio and observe that console window is allocated when Console is enabled. ## remarks about standard outputs I renamed some of the `ConsoleOutput` functions to `StandardOutput`, though only ones static to the scope of `log.cpp` for now. The terminology clarity can be helpful. The Console is very much a Microsoft Windows (MSW) term and is rarely used outside of the Windows ecosystem. Better terms are as follows: - Terminal (TTY) : this defines a window or socket/device that can receive Standard Output and provide Standard Input - Shell (Command Processor) : this defines an application that can receive Standard Input and execute commands, scripts, etc. and usually ensures any processes it creates have their standard pipes attached to the terminal (unless redirected). When you combine a Terminal with a Shell, you get an interactive Command Prompt we all know. You can run shells without the terminal, and you can run terminals without a shell. Windows Console is a terminal without a shell. Windows Terminal (the new UWP replacement for Console available on the Windows App Store) is also a terminal without a shell. Anyway, whether it's a terminal or console isn't important. What is important is that it's writing to "standard output" -- this is a construct that can, at the discretion of the invoking user or process, be either: - a terminal/console - a redirection to a file - a redirection to another process - a redirection to a socket or FIFO that can then be read asynchronously by other shells and processes (my favorite!) This was all part of the rationale for me renaming 'ConsoleOutput' to 'StandardOutput' ### `WIN32` vs. `_WIN32` I used `_WIN32` to identify the Windows SDK platform. I consider the define preferable as it's a first-class buildsystem define, similar to `_MSC_VER` / `__clang__` / `__ANDROID__`, etc. and such. By comparison, `WIN32` must be manually specified by the makefile/vcxproj. In many newer project templates, I've seen the define missing entirely. My recommendation is to migrate all your instances of `WIN32` to `_WIN32` at some point.

claunia added the pull-request label 2026-01-29 19:08:10 +00:00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: starred/duckstation#495

[PR #1394] Console: Fix problems when using CLI from MSYS2/GitBash/ConEmu #495

what it does

test cases

remarks about standard outputs

WIN32 vs. _WIN32

`WIN32` vs. `_WIN32`