[PR #8898] [MERGED] Add support for running a commandline in another WT window #27324

Open
opened 2026-01-31 09:21:20 +00:00 by claunia · 0 comments
Owner

📋 Pull Request Information

Original PR: https://github.com/microsoft/terminal/pull/8898
Author: @zadjii-msft
Created: 1/26/2021
Status: Merged
Merged: 2/10/2021
Merged by: @undefined

Base: mainHead: dev/migrie/f/the-first-galactic-empire


📝 Commits (10+)

  • 3bef7bb Get all the projects created and hooked up to the sln
  • 1f52d35 Yank all the M/P files, this builds?!
  • 5a9cdc8 Shockingly, this works, it works elevated, and it works unpackaged
  • 36539cf This won't work, but I'm committing this becaus I finally got it to compile a String[]
  • 27ace16 whoop, we pass the commandline from the peasant, to the monarch, and then back!
  • 9a41647 HOLY SHIT I GOT THE COMANDLINE TO EXECUTE IN THE CURRENT WINDOW!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
  • 5cabcfb add a note to future me
  • 03bfc6e This works as a unittest, but not a local test. That's batty
  • 590b9ff this macro makes me feel dirty
  • 0579b24 LocalTests_Remoting -> UnitTests_Remoting

📊 Changes

37 files changed (+1585 additions, -92 deletions)

View changed files

📝 .github/actions/spelling/expect/web.txt (+1 -0)
📝 OpenConsole.sln (+7 -4)
📝 src/cascadia/CascadiaPackage/CascadiaPackage.wapproj (+0 -1)
📝 src/cascadia/Remoting/CommandlineArgs.cpp (+2 -2)
📝 src/cascadia/Remoting/CommandlineArgs.h (+2 -2)
src/cascadia/Remoting/FindTargetWindowArgs.cpp (+5 -0)
src/cascadia/Remoting/FindTargetWindowArgs.h (+35 -0)
📝 src/cascadia/Remoting/Microsoft.Terminal.RemotingLib.vcxproj (+19 -0)
📝 src/cascadia/Remoting/Monarch.cpp (+195 -45)
📝 src/cascadia/Remoting/Monarch.h (+8 -3)
📝 src/cascadia/Remoting/Monarch.idl (+16 -1)
📝 src/cascadia/Remoting/Peasant.cpp (+54 -0)
📝 src/cascadia/Remoting/Peasant.h (+5 -1)
📝 src/cascadia/Remoting/Peasant.idl (+13 -2)
src/cascadia/Remoting/ProposeCommandlineResult.cpp (+5 -0)
src/cascadia/Remoting/ProposeCommandlineResult.h (+36 -0)
src/cascadia/Remoting/WindowActivatedArgs.cpp (+5 -0)
src/cascadia/Remoting/WindowActivatedArgs.h (+38 -0)
📝 src/cascadia/Remoting/WindowManager.cpp (+329 -9)
📝 src/cascadia/Remoting/WindowManager.h (+34 -3)

...and 17 more files

📄 Description

Summary of the Pull Request

If you're reading this PR and haven't signed off on #8135, go there first.

window-management-000

This provides the basic parts of the implementation of #4472. Namely:

  • We add support for the --window,-w <window-id> argument to wt.exe, to allow a commandline to be given to another window.
    • If window-id is 0, run the given commands in the current window.
    • If window-id is a negative number, run the commands in a new Terminal window.
    • If window-id is the ID of an existing window, then run the commandline in that window.
    • If window-id is not the ID of an existing window, create a new window. That window will be assigned the ID provided in the commandline. The provided subcommands will be run in that new window.
    • If window-id is omitted, then create a new window.

References

PR Checklist

Detailed Description of the Pull Request / Additional comments

Note that wt -w 1 -d c:\foo cmd.exe does work, by causing window 1 to change

There are limitations, and there are plenty of things to work on in the future:

  • We don't support names for windows yet
  • We don't support window glomming by default, or a setting to configure what happens when -w is omitted. I thought it best to lay the groundwork first, then come back to that.
  • -w 0 currently just uses the "last activated" window, not "the current". There's more follow-up work to try and smartly find the actual window we're being called from.
  • Basically anything else that's listed in projects/5.

I'm cutting this PR where it currently is, because this is already a huge PR. I believe the remaining tasks will all be easier to land, once this is in.

Validation Steps Performed

I've been creating windows, and closing them, and running cmdlines for a while now. I'm gonna keep doing that while the PR is open, till no bugs remain.

TODOs

  • There are a bunch of GetID, GetPID calls that aren't try/caught 😬
    • Monarch.cpp
    • Peasant.cpp
    • WindowManager.cpp
    • AppHost.cpp
  • If the monarch gets hung, then you can't launch any Terminals 😨 We should handle this gracefully.
    • Proposed idea: give the Monarch some time to respond to a proposal for a commandline. If there's no response in that timeframe, this window is now a hermit, outside of society entirely. It can't be elected Monarch. It can't receive command lines. It has no ID.
      • Could we gracefully recover from such a state? maybe, probably not though.
      • Same deal if a peasant hangs, it could end up hanging the monarch, right? Like if you do wt -w 2, and 2 is hung, then does the monarch get hung waiting on the hung peasant?
    • After talking with @miniksa, we're gonna punt this from the initial implementation. If people legit hit this in the wild, we'll fix it then.

🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.

## 📋 Pull Request Information **Original PR:** https://github.com/microsoft/terminal/pull/8898 **Author:** [@zadjii-msft](https://github.com/zadjii-msft) **Created:** 1/26/2021 **Status:** ✅ Merged **Merged:** 2/10/2021 **Merged by:** [@undefined](undefined) **Base:** `main` ← **Head:** `dev/migrie/f/the-first-galactic-empire` --- ### 📝 Commits (10+) - [`3bef7bb`](https://github.com/microsoft/terminal/commit/3bef7bbb389f7b048983bac8dda32af0e662a9fb) Get all the projects created and hooked up to the sln - [`1f52d35`](https://github.com/microsoft/terminal/commit/1f52d3583390e300b8253d605b5f79adac5e921b) Yank all the M/P files, this builds?! - [`5a9cdc8`](https://github.com/microsoft/terminal/commit/5a9cdc8b0bfda790a70368d8381559628eba554f) Shockingly, this works, it works elevated, and it works unpackaged - [`36539cf`](https://github.com/microsoft/terminal/commit/36539cfa47d1b5f3a3b0bf44f7bdcb057aa08e95) This won't work, but I'm committing this becaus I finally got it to compile a String[] - [`27ace16`](https://github.com/microsoft/terminal/commit/27ace166529367171fc81cef12aa4812e6ff8e13) whoop, we pass the commandline from the peasant, to the monarch, and then back! - [`9a41647`](https://github.com/microsoft/terminal/commit/9a41647ffe00d973f11478fb937221239d6ac81a) HOLY SHIT I GOT THE COMANDLINE TO EXECUTE IN THE CURRENT WINDOW!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! - [`5cabcfb`](https://github.com/microsoft/terminal/commit/5cabcfb45229f686d424c6d5a2fdfca7dd446639) add a note to future me - [`03bfc6e`](https://github.com/microsoft/terminal/commit/03bfc6e8a93c901ef00b34310c4e1c313019e720) This works as a unittest, but not a local test. That's batty - [`590b9ff`](https://github.com/microsoft/terminal/commit/590b9ff0c73487720a110213c4b19a2f4a00be8e) this macro makes me feel dirty - [`0579b24`](https://github.com/microsoft/terminal/commit/0579b2417bcdd74814ea05d7eb64723542584764) LocalTests_Remoting -> UnitTests_Remoting ### 📊 Changes **37 files changed** (+1585 additions, -92 deletions) <details> <summary>View changed files</summary> 📝 `.github/actions/spelling/expect/web.txt` (+1 -0) 📝 `OpenConsole.sln` (+7 -4) 📝 `src/cascadia/CascadiaPackage/CascadiaPackage.wapproj` (+0 -1) 📝 `src/cascadia/Remoting/CommandlineArgs.cpp` (+2 -2) 📝 `src/cascadia/Remoting/CommandlineArgs.h` (+2 -2) ➕ `src/cascadia/Remoting/FindTargetWindowArgs.cpp` (+5 -0) ➕ `src/cascadia/Remoting/FindTargetWindowArgs.h` (+35 -0) 📝 `src/cascadia/Remoting/Microsoft.Terminal.RemotingLib.vcxproj` (+19 -0) 📝 `src/cascadia/Remoting/Monarch.cpp` (+195 -45) 📝 `src/cascadia/Remoting/Monarch.h` (+8 -3) 📝 `src/cascadia/Remoting/Monarch.idl` (+16 -1) 📝 `src/cascadia/Remoting/Peasant.cpp` (+54 -0) 📝 `src/cascadia/Remoting/Peasant.h` (+5 -1) 📝 `src/cascadia/Remoting/Peasant.idl` (+13 -2) ➕ `src/cascadia/Remoting/ProposeCommandlineResult.cpp` (+5 -0) ➕ `src/cascadia/Remoting/ProposeCommandlineResult.h` (+36 -0) ➕ `src/cascadia/Remoting/WindowActivatedArgs.cpp` (+5 -0) ➕ `src/cascadia/Remoting/WindowActivatedArgs.h` (+38 -0) 📝 `src/cascadia/Remoting/WindowManager.cpp` (+329 -9) 📝 `src/cascadia/Remoting/WindowManager.h` (+34 -3) _...and 17 more files_ </details> ### 📄 Description ## Summary of the Pull Request **If you're reading this PR and haven't signed off on #8135, go there first.** ![window-management-000](https://user-images.githubusercontent.com/18356694/103932910-25199380-50e8-11eb-97e3-594a31da62d2.gif) This provides the basic parts of the implementation of #4472. Namely: * We add support for the `--window,-w <window-id>` argument to `wt.exe`, to allow a commandline to be given to another window. * If `window-id` is `0`, run the given commands in _the current window_. * If `window-id` is a negative number, run the commands in a _new_ Terminal window. * If `window-id` is the ID of an existing window, then run the commandline in that window. * If `window-id` is _not_ the ID of an existing window, create a new window. That window will be assigned the ID provided in the commandline. The provided subcommands will be run in that new window. * If `window-id` is omitted, then create a new window. ## References * Spec: #8135 * Megathread: #5000 * Project: projects/5 ## PR Checklist * [x] Closes #4472 * [x] I work here * [x] Tests added/passed * [ ] Requires documentation to be updated - **sure does** ## Detailed Description of the Pull Request / Additional comments Note that `wt -w 1 -d c:\foo cmd.exe` does work, by causing window 1 to change There are limitations, and there are plenty of things to work on in the future: * [ ] We don't support names for windows yet * [ ] We don't support window glomming by default, or a setting to configure what happens when `-w` is omitted. I thought it best to lay the groundwork first, then come back to that. * [ ] `-w 0` currently just uses the "last activated" window, not "the current". There's more follow-up work to try and smartly find the actual window we're being called from. * [ ] Basically anything else that's listed in projects/5. I'm cutting this PR where it currently is, because this is already a huge PR. I believe the remaining tasks will all be easier to land, once this is in. ## Validation Steps Performed I've been creating windows, and closing them, and running cmdlines for a while now. I'm gonna keep doing that while the PR is open, till no bugs remain. # TODOs * [x] There are a bunch of `GetID`, `GetPID` calls that aren't try/caught 😬 - [x] `Monarch.cpp` - [x] `Peasant.cpp` - [x] `WindowManager.cpp` - [x] `AppHost.cpp` * [x] If the monarch gets hung, then _you can't launch any Terminals_ 😨 We should handle this gracefully. - Proposed idea: give the Monarch some time to respond to a proposal for a commandline. If there's no response in that timeframe, this window is now a _hermit_, outside of society entirely. It can't be elected Monarch. It can't receive command lines. It has no ID. - Could we gracefully recover from such a state? maybe, probably not though. - Same deal if a peasant hangs, it could end up hanging the monarch, right? Like if you do `wt -w 2`, and `2` is hung, then does the monarch get hung waiting on the hung peasant? - After talking with @miniksa, **we're gonna punt this from the initial implementation**. If people legit hit this in the wild, we'll fix it then. --- <sub>🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.</sub>
claunia added the pull-request label 2026-01-31 09:21:20 +00:00
Sign in to join this conversation.
No Label pull-request
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/terminal#27324