[DxD] closeOnExit should be sensible when launched via defterm #17745

Closed
opened 2026-01-31 05:52:10 +00:00 by claunia · 4 comments
Owner

Originally created by @Andrew1988123123 on GitHub (Jun 19, 2022).

Originally assigned to: @PankajBhojwani on GitHub.

Windows Terminal version

Windows Terminal Version: 1.13.11432.0

Windows build number

Microsoft Windows [Version 10.0.22000.739]

Other Software

No response

Steps to reproduce

  1. Turn PC on
  2. Wait approximately 30min
  3. Windows Terminal opens with error "ERROR: The specified directory does not exist."

Expected Behavior

Windows Terminal shouldn't opens every time I turn PC on.

Actual Behavior

Every time I turn PC on and approximately after 30min Windows Terminal automatically opens new windows terminal with error "ERROR: The specified directory does not exist." WT startup is turned off. I don't use additional script to open WT.
Screenshot of the error https://prnt.sc/OTSf0FKHT9Dt
Full tab path C:\WINDOWS\System32\forfiles.exe

Originally created by @Andrew1988123123 on GitHub (Jun 19, 2022). Originally assigned to: @PankajBhojwani on GitHub. ### Windows Terminal version Windows Terminal Version: 1.13.11432.0 ### Windows build number Microsoft Windows [Version 10.0.22000.739] ### Other Software _No response_ ### Steps to reproduce 1. Turn PC on 2. Wait approximately 30min 3. Windows Terminal opens with error "ERROR: The specified directory does not exist." ### Expected Behavior Windows Terminal shouldn't opens every time I turn PC on. ### Actual Behavior Every time I turn PC on and approximately after 30min Windows Terminal automatically opens new windows terminal with error "ERROR: The specified directory does not exist." WT startup is turned off. I don't use additional script to open WT. Screenshot of the error https://prnt.sc/OTSf0FKHT9Dt Full tab path C:\WINDOWS\System32\forfiles.exe
Author
Owner

@zadjii-msft commented on GitHub (Jun 20, 2022):

Full tab path C:\WINDOWS\System32\forfiles.exe

Sounds like you've got the Windows Terminal set up as the default terminal emulator, and something you have installed is running a forfiles command. That forfiles is automatically launching in a Terminal window, instead of a console window. However, the Terminal doesn't automatically close when a commandline application exits with an error, unlike the console.

Now, trick here is that forfiles here isn't actually telling you what the missing directory is, just that it couldn't find it. I honestly don't know how you'd figure out who's launching that.

You might be able to mitigate this by setting closeOnExit: always in the profiles.defaults part of the settings.

I think we had previously discussed defterm invocations defaulting to that value - lemme bring that up with the team again.

@zadjii-msft commented on GitHub (Jun 20, 2022): > Full tab path C:\WINDOWS\System32\forfiles.exe Sounds like you've got the Windows Terminal set up as the default terminal emulator, and something you have installed is running a `forfiles` command. That `forfiles` is automatically launching in a Terminal window, instead of a console window. However, the Terminal doesn't automatically close when a commandline application exits with an error, unlike the console. Now, trick here is that `forfiles` here isn't actually telling you what the missing directory is, just that it couldn't find it. I honestly don't know how you'd figure out who's launching that. You might be able to mitigate this by setting [`closeOnExit: always`](https://docs.microsoft.com/en-us/windows/terminal/customize-settings/profile-advanced#profile-termination-behavior) in the `profiles.defaults` part of the settings. I think we had previously discussed defterm invocations defaulting to that value - lemme bring that up with the team again.
Author
Owner

@zadjii-msft commented on GitHub (Jul 8, 2022):

🌶️ take: for a defterm session, if the profile doesn't have a closeOnExit set, we treat that as always, instead of graceful. We'd need to change that setting to an optional, but because it gets exposed from Profile as a winrt type, it'd need to be an IReference<CloseOnExitMode>, which is a little gross.

@zadjii-msft commented on GitHub (Jul 8, 2022): 🌶️ take: for a defterm session, if the profile doesn't have a `closeOnExit` set, we treat that as `always`, instead of `graceful`. We'd need to change that setting to an optional, but because it gets exposed from `Profile` as a winrt type, it'd need to be an `IReference<CloseOnExitMode>`, which is a little gross.
Author
Owner

@zadjii-msft commented on GitHub (Jul 11, 2022):

discusssion:

  • is "close on exit" for things started by the Terminal? Can we just reframe graceful to "always" for defterm?
  • Meh, lets do the optional thing above?
  • Meh lets just just do always as the default?
  • Maybe we should have an setting between always and graceful "always so long as we actually got some bytes out of the connection"
  • but uhg, that's not actually helpful for defterm
  • you can't actually set graceful explicitly in the SUI - the profile will already say you're set to "graceful"
  • Maybe there needs to be "gracefulIfLaunchedByTerminal", which is the new default, which is "always" for defterm. It's annoying but okay.
@zadjii-msft commented on GitHub (Jul 11, 2022): discusssion: * is "close on exit" for _things started by the Terminal_? Can we just reframe `graceful` to "always" for defterm? * Meh, lets do the optional thing above? * Meh lets just just do always as the default? * Maybe we should have an setting between always and graceful "always so long as we actually got some bytes out of the connection" * but uhg, that's not actually helpful for defterm * you can't actually _set_ graceful explicitly in the SUI - the profile will already say you're set to "graceful" * **Maybe there needs to be "gracefulIfLaunchedByTerminal", which is the new default, which is "always" for defterm. It's annoying but okay.**
Author
Owner

@ghost commented on GitHub (Aug 18, 2022):

:tada:This issue was addressed in #13560, which has now been successfully released as Windows Terminal Preview v1.15.228.🎉

Handy links:

@ghost commented on GitHub (Aug 18, 2022): :tada:This issue was addressed in #13560, which has now been successfully released as `Windows Terminal Preview v1.15.228`.:tada: Handy links: * [Release Notes](https://github.com/microsoft/terminal/releases/tag/v1.15.228) * [Store Download](https://www.microsoft.com/store/apps/9n8g5rfz9xk3?cid=storebadge&ocid=badge)
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/terminal#17745