Option to allocate a pseudo-terminal for running command-line applications

[Tyrrrz]

Details

Sometimes, command-line applications may behave differently, depending on whether they execute in a real console environment (i.e. when the user runs them from a terminal) or in a scripting environment (i.e. when the user runs them using CliWrap). This is typically done by checking whether the standard input, output, and/or error stream are redirected (if yes, it implies a scripting environment) and adjusting the behavior accordingly.

Most of the time, the difference in behavior is not consequential. The application may opt to render slightly simpler output (e.g. no progress reporting, no pretty tables, etc.) if it detects that the corresponding stream is redirected. However, this may not always be desirable, as there are scenarios where the user may still want to get the "real" behavior, even in a scripting environment: #48 #87 #113 #140 #208.

Typically, this is worked around by creating a pseudo-terminal — a programming interface that acts just like a real terminal, but has no visual component and simply relays data between the user and another program.

On Unix-based platforms, allocating a pseudo-terminal is relatively easy — either through the forkpty function or the script built-in tool.

On Windows, it's possible to achieve the same result either via the unofficial winpty tool or, since Windows 10, using the conpty Win32 API. There's also a sample for integrating the latter available here.

We should find a way to expose this functionality via CliWrap, so that the user is able to run a command-line application in such a way, that it thinks that it operates against a real console (i.e. std streams are not redirected). Internally, this would work by leveraging one of the approaches described above, depending on the current system. Externally, this functionality should be provided through a new configuration method: Command.WithPseudoConsole(bool = true) (keep the "console" nomenclature to stay consistent with Windows-derived naming, as is the tradition in .NET).

Also, consider whether this feature has any conflict with the "graceful cancellation" feature, as the latter relies on attaching to a new console for sending interrupt signals on Windows.

Checklist

• I have looked through existing issues to make sure that this feature has not been requested before
• I have provided a descriptive title for this issue
• I am aware that even valid feature requests may be rejected if they do not align with the project's goals
• I have sponsored this project