in reply to WIN redirecting STDOUT and STDIN to new spawned CMD console

"That's not too unheard off, the second window is similar to a GUI app which writes errors into the original console."

This isn't exactly as easy as it sounds, especially given the difficulty of transferring environment from one console to another. In berrybrew, doing what you suggest means having one app (ie. GUI) communicating with a backend that also communicates to another app (CMD window) to display any output. That 'kind of' happens in debug mode, but only artificially.

The GUI is typically started from the CMD, so in this case it is the backend that communicates to the other window, but one way or another, you have to start another shell if you want to trap it there. It's unfortunately not as easy as a tee

If this problem could ever be solved especially if the environment could be carried from one CMD to another, I could remove a couple hundred lines of C# and make great efficiencies :)

I have literally been waiting for a solution to this specific question for a long time. I just didn't know how to ask it.

Replies are listed 'Best First'.
Re^2: WIN redirecting STDOUT and STDIN to new spawned CMD console
by LanX (Saint) on Mar 28, 2023 at 14:00 UTC
    Thanks, I didn't know it's that complicated.

    My approach to Win is to mentally map concepts I know from Linux, even after years. And this doesn't always fit.

    I also kind of remembered that a child process is inheriting STD-IN/OUT/ERR from the parent.

    So one of my ideas was that probably it was possible than an app spawns a console as child with "cloned" STDIN and STDOUT, while STDERR is kept to the parent's console.

    Cheers Rolf
    (addicted to the 𐍀𐌴𐍂𐌻 Programming Language :)
    Wikisyntax for the Monastery