How do I close ConPty Std Input?

[gerardog]

Hi. First of all, thanks for all the great work being done!

If I open console app with its input redirected in a classic console, when the input ends the console app can act accordingly:

For example:

:: Create command
C:\Users\gerar>Echo Prompt [TEST] $P$g > MyCommand
C:\Users\gerar>Echo cd .. >> MyCommand

:: Execute with redirected input
C:\Users\gerar>cmd < MyCommand

Microsoft Windows [Version 10.0.19043.1165]
(c) Microsoft Corporation. All rights reserved.

C:\Users\gerar>Prompt [TEST] $P$g

[TEST] C:\Users\gerar> cd ..
[TEST] C:\Users>

:: Child CMD detects End of Input and terminates automatically. 
C:\Users\gerar> 

I am trying to replicate this using ConPty with no luck. If I create a pseudoconsole, send the input but then try closing the input stream (hInput) to signal end-of-input, with different approaches, but none of them seems to work. The client console app keeps waiting for more input.

How can I signal the console app running in a pseudoconsole that the input has ended?

Thanks!

[orcmid]

I don't think this is a terminal-specific issue and its not exactly about closing stdin..

If I use, for example, the "Developer Command Prompt for VS 2019" or my preference, the "x64 Native Tools Command Prompt for VS 2019" and I launch VS Code via command "code .", I will have a stuck cmd.exe window, and closing VS Code makes no difference. I can do better with "start code ." except that is because a separate cmd.exe window is opened in launching VS Code and that one is stuck.

This seems to be the classic problem of (1) not being able to tell when an applications exits if it doesn't exit like a console application and/or (2) not having information to know that there is no need to wait because a non-console app is being launched.

[gerardog]

Hi @orcmid, we are talking about different things. This question is not about the Windows Terminal app, but how to use the PseudoConsole API (ConPty).

You are describing the issue that an EXE file can be of different types. A console app will block the console, a windows app would not. VSCode is a Win App with a code.cmd file in the path that wraps it, thus when you code . you actually are calling a CMD.EXE console app batch that launches a windows app, confusing but totally unrelated.

I am talking about console apps specifically, that reads from StdIn. When StdIn is closed or EOF arrives, the console app knows, stops waiting and closes. For example do CMD /c < SomeEmptyFile.txt.

Now, I have a C# app that is using CreatePseudoConsole Api to call a console App (let's say it is CMD). I´ve written all the desired input to the input stream and I want to signal that the input has come to an end. I expect that CMD.EXE to end (same as it does when the input ends on ConHost. How do I do that? I tried closing the input pipe but CMD.EXE is still waiting for more input.

[orcmid]

@gerardog my use of the VS 2019 command prompts are all with cmd.exe, not Windows Terminal. When I do D:> code . I don't see a new cmd.exe, I see the one I do the command in be stuck. If I do D:>start code . I see an additional cmd.exe session that is then stuck.

I have not changed my system to use terminal for cmd.exe.

My only point is that the phenomenon does not seem to be specific to Windows Terminal and/or operating a program under a PseudoConsole connection. I guess it is not analogous though.

In your case,

Now, I have a C# app that is using CreatePseudoConsole Api to call a console App (let's say it is CMD). I´ve written all the desired input to the input stream and I want to signal that the input has come to an end.

I assume Creating a PseudoConsole Session applies. Is it correct that your program will spawn a console mode program with your program situated as if an user, specifying its stdin and consuming its stdout. That's what you mean when speaking of writing to input?

Is your issue that the (hosted) program does not terminate when your (hosting) program closes the stream that is its stdin? Is that not more about whether the hosted program can determine that and whether it actually does?

[gerardog]

Is your issue that the (hosted) program does not close when your (hosting) program closes the stream that is its stdin?

I'm asking how to signal end of input to a ConPty hosted app. The process will end as a natural consequence. I do not want to close the program myself.

[gerardog]

Is that not more about whether the hosted program can determine that and whether it actually does?

No, The hosted program is CMD.EXE and it certainly knows how to handle EOF. If it is not reacting accordingly is because I am not signaling EOF properly via ConPty, thus the question.

[orcmid]

and "\nexit\n" doesn't do it?

[gerardog]

No. The hosted app will actually be any console app the end user will want. I just mentioned CMD to remove noise from the equation,

Maybe related: #4585

[orcmid]

No. The hosted app will actually be any console app the end user will want. I just mentioned CMD to remove noise from the equation,

Well, does "\nexit\n" work with CMD though? That may be forensically informative.

What do you do for console applications that never access stdin?

[sajagi]

This seems to be still an issue. When I close the handle of write-part of anonymous pipe used for stdInput, no EOF is signalled to the ConPty-hosted application. When I launch the application directly (without using pseudoconsole) the behavior works as expected. Also tried closing the pipe (the write part) before calling CreatePseudoConsole, no luck.

[sajagi]

Looking at the prior discussion I'd like to point out that it is absolutely unrelated to a shell app (like cmd.exe). In my case I am using a .NET application which in turn spawns a new process using CreateProcess function while passing a handle to a pseudoconsole.

[lhecker]

I've recently made a ton of improvements around the ConPTY shutdown behavior: #14544. The PR lists 4 additional PRs that are next to the "Depends on:" line. It should make shutdown much more robust when you close the stdin pipe of ConPTY.

It additionally adds a function called ConptyReleasePseudoConsole. If you call this on a HPCON you can then just read from stdout until the pipe gets closed on you, because that signals that the process you've spawned has exited. So there's no need to separately monitor the exit status of the process anymore.

The proper way to make the spawned process exit early is for you to drop the stdin pipe (= the pipe you write into) and (!) call ConptyClosePseudoConsole or the newly added ConptyClosePseudoConsoleTimeout. As mentioned on MSDN, you must continue reading from the stdout pipe (= the pipe you read from) though until it gets closed on you. Since ConptyClosePseudoConsole blocks until the application you've spawned has exited, calling this function on the same thread you're reading from the stdout pipe might deadlock you. This is why ConptyClosePseudoConsoleTimeout was added, because it allows you to pass a timeout of 0, which effectively turns this into an async shutdown.

Thus, ConptyReleasePseudoConsole in combination with ConptyClosePseudoConsoleTimeout and a timeout of 0, allows you to simply read from the stdout pipe until it gets closed, without the need to spawn any extra threads.

Unfortunately it'll take a long time to release this as part of the official operating system API, due to the new, lengthy update cycle of Windows 11. The current, alternative recommendation is to bundle OpenConsole.exe from this repository (the latest releases contain signed binaries inside the .msixbundle files) and statically link with a matching version of winconpty. Publishing a precompiled nuget package is on the backlog I believe.