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

Incompatibility with console programs #19468

New Issue
Open
opened 2026-01-31 06:44:14 +00:00 by claunia · 0 comments
claunia commented 2026-01-31 06:44:14 +00:00
Owner
Copy Link

Originally created by @v-python on GitHub (Feb 28, 2023).

Originally assigned to: @DHowett on GitHub.

Windows Terminal version

No response

Windows build number

No response

Other Software

Python 3.11.1

Steps to reproduce

I have a Python program that launches other programs, some are console programs, some are GUI, and then exits.

On Windows 10, using console, the python program (started from a GUI) initiates a console windows, writes a little info on the console, then launches the other program, and and exits. If the other program is a GUI, the console goes away quickly, and the GUI persists until the user exits. If the other program is a console program, it continues to use the console that is created for the Python program, even after the Python program exits.

This is all as expected and working fine.

However, I have all this stuff on Dropbox, and some of my users have upgraded to Windows 11, and it is not working fine. The case that is not working, is when the other program launched by the Python program is a console program. The other program dies "approximately concurrently" with the Python program. For debugging, I added a 5 minute timer at the point where the Python program would otherwise exit, and so it sticks around long enough to determine that it does, in fact, still launch the other program, and the other program is quite usable for 5 minutes... and then when the Python program timer expires and it exits, so does the other program.

Researching this eventually led me to the discovery that Windows Terminal is now the default for supplying console windows on Windows 11. I eventually discovered that there are some advanced settings regarding CloseOnExit for Windows Terminal: "graceful", "always", "never", true, false. I have little idea what really happens here, because I don't use Windows 11, I don't have Windows Terminal installed on Windows 10, I don't know if installing Windows Terminal on Windows 10 would result in the same behaviors, since I guess it wouldn't be the default? I don't really want to alter my working Windows 10 environment by experimenting. But I would expect that things should be compatible by default, and they aren't.

From what I can read, "CloseOnExit" may only concern itself with the immediate child process, and that could be the problem. From what I understand about Console, it closes when there are no processes still using it, allowing things to work as expected on Windows 10. Does Windows Terminal need a new "CloseOnExit" setting that means "Close when all programs using the tab have closed the tab"? Would that allow compatibility with Windows 10 Console? Shouldn't that be the default setting for Windows Terminal?

I found a screenshot of Windows Terminal CloseOnExit settings, and the list of settings was only 4, and while "never" mapped, I'm not sure what "automatic" in the screen shot corresponds to in the above list. "automatic" sounds good, but should wait for all users to close it, rather than process death. Or maybe there is some other setting I haven't found.

In any case, this seems to be an environmental incompatibility with Windows 10.

If I detect Windows 11 (which identifies as Windows 10, making that far harder than it should be), and have the Python program wait for its child, that leaves the annoying console open when the child is a GUI.

I have no idea what version of Windows 11 or Windows Terminal is being used on these other systems, but from what I know about the people involved, it is likely the automatic release channel, with updates being applied when available.

Expected Behavior

Program should be allow to run to completion in its parent's console.

Actual Behavior

Console programs terminate too early.

Originally created by @v-python on GitHub (Feb 28, 2023). Originally assigned to: @DHowett on GitHub. ### Windows Terminal version _No response_ ### Windows build number _No response_ ### Other Software Python 3.11.1 ### Steps to reproduce I have a Python program that launches other programs, some are console programs, some are GUI, and then exits. On Windows 10, using console, the python program (started from a GUI) initiates a console windows, writes a little info on the console, then launches the other program, and and exits. If the other program is a GUI, the console goes away quickly, and the GUI persists until the user exits. If the other program is a console program, it continues to use the console that is created for the Python program, even after the Python program exits. This is all as expected and working fine. However, I have all this stuff on Dropbox, and some of my users have upgraded to Windows 11, and it is not working fine. The case that is not working, is when the other program launched by the Python program is a console program. The other program dies "approximately concurrently" with the Python program. For debugging, I added a 5 minute timer at the point where the Python program would otherwise exit, and so it sticks around long enough to determine that it does, in fact, still launch the other program, and the other program is quite usable for 5 minutes... and then when the Python program timer expires and it exits, so does the other program. Researching this eventually led me to the discovery that Windows Terminal is now the default for supplying console windows on Windows 11. I eventually discovered that there are some advanced settings regarding CloseOnExit for Windows Terminal: "graceful", "always", "never", true, false. I have little idea what really happens here, because I don't use Windows 11, I don't have Windows Terminal installed on Windows 10, I don't know if installing Windows Terminal on Windows 10 would result in the same behaviors, since I guess it wouldn't be the default? I don't really want to alter my working Windows 10 environment by experimenting. But I would expect that things should be compatible by default, and they aren't. From what I can read, "CloseOnExit" may only concern itself with the immediate child process, and that could be the problem. From what I understand about Console, it closes when there are no processes still using it, allowing things to work as expected on Windows 10. Does Windows Terminal need a new "CloseOnExit" setting that means "Close when all programs using the tab have closed the tab"? Would that allow compatibility with Windows 10 Console? Shouldn't that be the default setting for Windows Terminal? I found a screenshot of Windows Terminal CloseOnExit settings, and the list of settings was only 4, and while "never" mapped, I'm not sure what "automatic" in the screen shot corresponds to in the above list. "automatic" sounds good, but should wait for all users to close it, rather than process death. Or maybe there is some other setting I haven't found. In any case, this seems to be an environmental incompatibility with Windows 10. If I detect Windows 11 (which identifies as Windows 10, making that far harder than it should be), and have the Python program wait for its child, that leaves the annoying console open when the child is a GUI. I have no idea what version of Windows 11 or Windows Terminal is being used on these other systems, but from what I know about the people involved, it is likely the automatic release channel, with updates being applied when available. ### Expected Behavior Program should be allow to run to completion in its parent's console. ### Actual Behavior Console programs terminate too early.
claunia added the Issue-BugNeeds-Tag-FixNeeds-Author-Feedback labels 2026-01-31 06:44:14 +00:00
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 Issue-Bug Needs-Author-Feedback Needs-Tag-Fix
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#19468
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?