starred/terminal
1
0
Fork 0
mirror of https://github.com/microsoft/terminal.git synced 2026-02-03 21:25:34 +00:00
Code Issues 19.0k Packages Projects Releases 20 Wiki Activity

How do I close ConPty Std Input? #14932

New Issue
Closed
opened 2026-01-31 04:23:34 +00:00 by claunia · 10 comments
claunia commented 2026-01-31 04:23:34 +00:00
Owner
Copy Link

Originally created by @gerardog on GitHub (Aug 22, 2021).

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!

Originally created by @gerardog on GitHub (Aug 22, 2021). 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: ``` cmd :: 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!
claunia added the Needs-TriageNeeds-Tag-FixProduct-Conpty labels 2026-01-31 04:23:35 +00:00
claunia commented 2026-01-31 04:23:36 +00:00
Author
Owner
Copy Link

@orcmid commented on GitHub (Aug 22, 2021):

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.

@orcmid commented on GitHub (Aug 22, 2021): 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.
claunia commented 2026-01-31 04:23:36 +00:00
Author
Owner
Copy Link

@gerardog commented on GitHub (Aug 22, 2021):

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.

@gerardog commented on GitHub (Aug 22, 2021): 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.
claunia commented 2026-01-31 04:23:36 +00:00
Author
Owner
Copy Link

@orcmid commented on GitHub (Aug 22, 2021):

@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?

@orcmid commented on GitHub (Aug 22, 2021): @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]( https://docs.microsoft.com/en-us/windows/console/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?
claunia commented 2026-01-31 04:23:37 +00:00
Author
Owner
Copy Link

@gerardog commented on GitHub (Aug 23, 2021):

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 commented on GitHub (Aug 23, 2021): > 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.
claunia commented 2026-01-31 04:23:37 +00:00
Author
Owner
Copy Link

@gerardog commented on GitHub (Aug 23, 2021):

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.

@gerardog commented on GitHub (Aug 23, 2021): > 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.
claunia commented 2026-01-31 04:23:37 +00:00
Author
Owner
Copy Link

@orcmid commented on GitHub (Aug 23, 2021):

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

@orcmid commented on GitHub (Aug 23, 2021): and "\nexit\n" doesn't do it?
claunia commented 2026-01-31 04:23:37 +00:00
Author
Owner
Copy Link

@gerardog commented on GitHub (Aug 23, 2021):

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

@gerardog commented on GitHub (Aug 23, 2021): 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
claunia commented 2026-01-31 04:23:38 +00:00
Author
Owner
Copy Link

@orcmid commented on GitHub (Aug 23, 2021):

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?

@orcmid commented on GitHub (Aug 23, 2021): > 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`?
claunia commented 2026-01-31 04:23:38 +00:00
Author
Owner
Copy Link

@sajagi commented on GitHub (Jan 7, 2022):

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 commented on GitHub (Jan 7, 2022): 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.
claunia commented 2026-01-31 04:23:38 +00:00
Author
Owner
Copy Link

@sajagi commented on GitHub (Jan 8, 2022):

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.

@sajagi commented on GitHub (Jan 8, 2022): 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.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
⛺ Reserved
A11yCO
A11yMAS
A11ySev1
A11ySev2
A11ySev3
A11yTTValidated
A11yUsable
A11yVoiceAccess
A11yWCAG
Area-Accessibility
Area-AtlasEngine
Area-AzureShell
Area-Build
Area-Build
Area-Chat
Area-CmdPal
Area-CodeHealth
Area-Commandline
Area-CookedRead
Area-DefApp
Area-Extensibility
Area-Fonts
Area-GroupPolicy
Area-i18n
Area-Input
Area-Interaction
Area-Interop
Area-Localization
Area-Output
Area-Performance
Area-Portable
Area-Quality
Area-Remoting
Area-Rendering
Area-Schema
Area-Server
Area-Settings
Area-SettingsUI
Area-ShellExtension
Area-ShellExtension
Area-ShellExtension
Area-Suggestions
Area-Suggestions
Area-TerminalConnection
Area-TerminalControl
Area-Theming
Area-UserInterface
Area-VT
Area-Windowing
Area-WPFControl
AutoMerge
Blocking-Ingestion
Culprit-Centennial
Culprit-WinUI
Disability-All
Disability-Blind
Disability-LowVision
Disability-Mobility
External-Blocked-WinUI3
Fixed
Gathering-Data
good first issue
HCL-E+D
HCL-WindowsTerminal
Help Wanted
Impact-Compatibility
Impact-Compliance
Impact-Correctness
Impact-Visual
In-PR
InclusionBacklog
InclusionBacklog-Windows TerminalWin32
InclusionCommitted-202206
Issue-Bug
Issue-Docs
Issue-Feature
Issue-Feature
Issue-Question
Issue-Samples
Issue-Scenario
Issue-Task
Needs-Attention
Needs-Author-Feedback
Needs-Bisect
Needs-Discussion
Needs-Repro
Needs-Tag-Fix
Needs-Tag-Fix
Needs-Triage
No-Recent-Activity
Priority-0
Priority-1
Priority-2
Priority-3
Product-Cmd.exe
Product-Colortool
Product-Colortool
Product-Colortool
Product-Conhost
Product-Conpty
Product-Meta
Product-Powershell
Product-Terminal
Product-WSL
pull-request
Mirrored from GitHub Pull Request
 Resolution-Answered
Resolution-By-Design
Resolution-Duplicate
Resolution-External
Resolution-Fix-Available
Resolution-Fix-Committed
Resolution-No-Repro
Resolution-Won't-Fix
Severity-Blocking
Severity-Crash
Severity-DataLoss
spam
this-will-be-a-breaking-change
Tracking-External
WindowsTerminal_Win32
Work-Item
zAskModeBug
zInbox-Bug
No Label Needs-Tag-Fix Needs-Triage Product-Conpty
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
claunia
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/terminal#14932
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?