Add support for wt.exe to run commands in an existing Terminal Window #4472

Danthar · 2020-02-05T08:53:12Z

Description of the new feature/enhancement

I have been playing around with Jetbrains Rider, and when i start a console app with that IDE, it runs the console window inside a docked window in the IDE.

So what i was thinking. How cool would it be, if Windows Terminal allows external applications to start a new Console window in the currently running Windows Terminal instance.

That way whether its VisualStudio or Rider, those IDE's can be configured to start a new Console window inside the Windows Terminal instance.

The way i see this working is: I press F5/ctrl-F5 in visual studio, and instead of opening a new cmd console window, a new tab appears in my running Windows Terminal instance.

lostmsu · 2020-02-06T04:19:29Z

Yes, please. There's a Visual Studio extension, that lets you open command line in the current project folder. I set it to launch wt.exe, and it always creates a new window, but I'd love if I could pass a parameter to wt.exe, so that if Terminal is already running, it would be activated a new tab would open there instead.

DHowett-MSFT · 2020-02-07T17:15:15Z

Thanks for the request! I thought we had a backlog item for "allow remote control of a terminal" (like: wt.exe could --remote to control another open instance and add tabs or whatever), but it looks like we don't.

This is now that issue. Triaged into backlog.

/cc @zadjii-msft: I may be wrong in not finding a "remote control" issue

DHowett-MSFT · 2020-02-07T17:16:25Z

Partially supported by #2080.

zadjii-msft · 2020-02-07T17:47:25Z

This was briefly mentioned in this spec

Future considerations

These are some additional argument ideas which are dependent on other features
that might not land for a long time. These features were still considered as a
part of the design of this solution, though their implementation is purely
hypothetical for the time being.

Instead of launching a new Windows Terminal window, attach this new
terminal to an existing one. This would require the work outlined in
[Spec for tab tear off and default app #2080], so support a "manager" process that could coordinate sessions
like this.

This would be something like wt --session [some-session-id] [commands], where --session [some-session-id] would tell us that
[more-commands] are intended for the given other session/window.
That way, you could open a new tab in another window with wt --session 0 cmd.exe (for example).

list-sessions: A command to display all the active Windows terminal
instances and their session ID's, in a way compatible with the above
command. Again, heavily dependent upon the implementation of [Spec for tab tear off and default app #2080].

Which yea is part of #2080, but I don't think has it's own issue.

Rumbah2 · 2020-02-14T03:03:01Z

Wow, I was just thinking about "starting a new program/task in any existing windows terminal window" or a "single instance mode" to populate a WT window with multiple tasks via CLI would be great.
But something like sessions would be even better and more flexible.

But I admit that I'd prefer a "quick and dirty" single instance mode in the near future over a flexible session management in the distant future (as I could use it sooner than later).

mreymann · 2021-03-12T11:16:00Z

I didn't even know calling Windows binaries works at all! ;-) cmd.exe works, wt.exe doesn't:

[12:14:33][pigpen@box:~]$ which wt.exe
/mnt/c/Users/<USER>/AppData/Local/Microsoft/WindowsApps/wt.exe

[12:15:03][pigpen@box:~]$ strace wt.exe
execve("/mnt/c/Users/<USER>/AppData/Local/Microsoft/WindowsApps/wt.exe", ["wt.exe"], 0x7ffff5c7a1b0 /* 24 vars */) = -1 ENOEXEC (Exec format error)
strace: exec: Exec format error
+++ exited with 1 +++

fredrikhr · 2021-03-12T11:20:34Z

@mreymann Yeah, this is caused by this AppContainer isolation layer of Appx Packages (Microsoft Store apps) and how their executables are placed in the %LOCALAPPDATA%\Microsoft\WindowsApps folder. The files in there both are and are not there or at least are not really executable, but the Windows OS does some weird magic trick to actually start the correct binary from wherever the App is actully installed. Which is why starting the exe from a windows-shell starting point works, whereas from a WSL2-starting point it does not.

Would be interesting whether the technology used in WSL1 leads to this actually working, or not...

This finishes the implementation of `--window` to also accept a string as the "name" of the window. So you can say ```sh wt -w foo new-tab wt -w foo split-pane ``` and have both those commands execute in the same window, the one named "foo". This is just slightly more ergonomic than manually using the IDs of windows. In the future, I'll be working on renaming windows, and displaying these names. > #### `--window,-w <window-id>` > Run these commands in the given Windows Terminal session. This enables opening > new tabs, splits, etc. in already running Windows Terminal windows. > * If `window-id` is `0`, run the given commands in _the current window_. > * If `window-id` is a negative number, or the reserved name `new`, run the > commands in a _new_ Terminal window. > * If `window-id` is the ID or name of an existing window, then run the > commandline in that window. > * If `window-id` is _not_ the ID or name of an existing window, create a new > window. That window will be assigned the ID or name provided in the > commandline. The provided subcommands will be run in that new window. > * If `window-id` is omitted, then obey the value of `windowingBehavior` when > determining which window to run the command in. Before this PR, I think we didn't actually properly support assigning the id with `wt -w 12345`. If `12345` didn't exist, it would make a new window, but just assign it the next id, not assign it 12345. ## References * #4472, #8135 * https://github.com/microsoft/terminal/projects/5 ## Validation Steps Performed Ran tests Messed with naming windows, working as expected. Closes https://github.com/microsoft/terminal/projects/5#card-51431478

JenuelDev · 2021-04-21T11:58:48Z

If someone needs the commands to create a new tab (and not open a new window) from a context menu item are:

(if you are already in the directory):
wt -w 0 nt

(and if you click on the directory):
wt -w 0 nt -d %1

You can add these commands in the respective registry of each item (or in a new one)

this really works it open a new tab, the problem is the directory was reset,.. hoping that I open a new tab, it will be at the same directory in my working project.

santanaruben · 2021-04-21T14:35:00Z

@BroJenuel

The first case was a modification.
The second one I had to create.

### ⇒ [doc link](https://github.com/microsoft/terminal/blob/dev/migrie/s/653-quake-mode/doc/specs/%23653%20-%20Quake%20Mode/%23653%20-%20Quake%20Mode.md) ⇐ ## Summary of the Pull Request After reading through 114+ comments in #653 and related issues, I think I've finally wrapped my head around all the possible scenarios for quake mode.  This also includes "minimize to tray", because the two are a powerful combination. With the work already prototyped in [`dev/migrie/f/653-QUAKE-MODE`](https://github.com/microsoft/terminal/tree/dev/migrie/f/653-QUAKE-MODE), [I'm starting to believe](https://j.gifs.com/58vKNx.gif) that we could actually land this in 2.0. ### Abstract > Many existing terminals support a feature whereby a user can press a keybinding > anywhere in the OS, and summon their terminal application. Oftentimes the act of > summoning this window is accompanied by a "dropdown" animation, where the window > slides in to view from the top of the screen. This global summon action is often > referred to as "quake mode", a reference to the videogame Quake who's console > slid in from the top. > > This spec addresses both of the following two issues: > * "Quake Mode" ([#653]) > * "Minimize to tray" ([#5727]) ## PR Checklist * [x] Specs: #653, #5727 * [x] References: #5000, #4472, #2227, #7240, #8135 * [x] I work here ## Detailed Description of the Pull Request / Additional comments _\*\*\* read the spec \*\*\*_

### ⇒ [doc link](https://github.com/microsoft/terminal/blob/dev/migrie/s/1032-elevation-qol/doc/specs/%235000%20-%20Process%20Model%202.0/%231032%20-%20Elevation%20Quality%20of%20Life%20Improvements.md) ⇐ ## Summary of the Pull Request Despite my best efforts to mix elevation levels in a single Terminal window, it seems that there's no way to do that safely. With the dream of mixed elevation dead, this spec outlines a number of quality-of-life improvements we can make to the Terminal today. These should make using the terminal in elevated scenarios better, since we can't have M/E. ### Abstract > For a long time, we've been researching adding support to the Windows Terminal > for running both unelevated and elevated (admin) tabs side-by-side, in the same > window. However, after much research, we've determined that there isn't a safe > way to do this without opening the Terminal up as a potential > escalation-of-privilege vector. > > Instead, we'll be adding a number of features to the Terminal to improve the > user experience of working in elevated scenarios. These improvements include: > > * A visible indicator that the Terminal window is elevated ([#1939]) > * Configuring the Terminal to always run elevated ([#632]) > * Configuring a specific profile to always open elevated ([#632]) > * Allowing new tabs, panes to be opened elevated directly from an unelevated > window > * Dynamic profile appearance that changes depending on if the Terminal is > elevated or not. ([#1939], [#8311]) ## PR Checklist * [x] Specs: #1032, #632 * [x] References: #5000, #4472, #2227, #7240, #8135, #8311 * [x] I work here ## Detailed Description of the Pull Request / Additional comments _\*\*\* read the spec \*\*\*_ ### Why are these two separate documents? I felt that the spec that is currently in review in #7240 and this doc should remain separate, yet closely related documents. #7240 is more about showing how this large set of problems discussed in #5000 can all be solved technically, and how those solutions can be used together. It establishes that none of the proposed solutions for components of #5000 will preclude the possibility of other components being solved. What it does _not_ do however is drill too deeply on the user experience that will be built on top of those architectural changes. This doc on the other hand focuses more closely on a pair of scenarios, and establishes how those scenarios will work technically, and how they'll be exposed to the user.

androiddevnotes · 2021-08-27T19:04:02Z

If someone needs the commands to create a new tab (and not open a new window) from a context menu item are:
(if you are already in the directory):
wt -w 0 nt
(and if you click on the directory):
wt -w 0 nt -d %1
You can add these commands in the respective registry of each item (or in a new one)

this really works it open a new tab, the problem is the directory was reset,.. hoping that I open a new tab, it will be at the same directory in my working project.

Try this:

wt -w 0 nt -d .

lfr · 2021-08-30T09:24:32Z

And what would the commands be to open a new tab from within the terminal itself?

zadjii-msft · 2021-08-30T13:45:24Z

wt -w 0 nt

lfr · 2021-08-30T14:04:53Z

@zadjii-msft thanks, but it doesn't seem to work from bash (Terminal Preview) 🤷‍♂️

zadjii-msft · 2021-08-30T14:10:41Z

Ah, from WSL you'll need:

cmd.exe /c "wt.exe" -w 0 nt

Execution aliases do not work in WSL distributions. If you want to use wt.exe from a WSL command line, you can spawn it from CMD directly by running cmd.exe. The /c option tells CMD to terminate after running.

Also, you can read this in the docs

hardeepparmar · 2021-08-30T16:19:49Z

wt -w 0 nt

But this works only from with in cmd tab window.. This does not work if you issue this command from say within powershell tabbed window.

zadjii-msft · 2021-08-30T16:25:02Z

But this works only from with in cmd tab window.. This does not work if you issue this command from say within powershell tabbed window.

🤔

DJackman123 · 2021-08-30T16:32:53Z

Beat me to the punch. Yes, it does work in a PowerShell tab. However, it does not work in a Windows Terminal window running as administrator (see #9628).

hardeepparmar · 2021-09-01T23:01:59Z

Beat me to the punch. Yes, it does work in a PowerShell tab. However, it does not work in a Windows Terminal window running as administrator (see #9628).

Yes indeed i am running Windows terminal as Administrator and I see this issue...However as you said, if I do not run at as administrator, it works just as expected. Thanks for confirming and making it more explicit and clear.

MetaMmodern · 2022-02-12T20:32:54Z

For those who are kinda new to this: here is how you can do it the easy way.(Works for me in Windows 10 Pro with Windows Terminal(not Preview))

Open Windows Terminal.
Open Settings.
Checkout this section in the startup menu.
Select as I did.
Test by clicking "Open in Windows Terminal" elsewhere.
Thanks Microsoft for adding this to GUI)

LawranceFung · 2022-02-13T01:52:15Z

For those who are kinda new to this: here is how you can do it the easy way.

1. Open Windows Terminal.

2. Open Settings.

3. Checkout this section in the startup menu.
   ![image](https://user-images.githubusercontent.com/42899786/153727389-56f004b6-cd7b-4b35-9531-ef2227e28638.png)

4. Select as I did.

5. Test by clicking "Open in Windows Terminal" elsewhere.
   Thanks Microsoft for adding this to GUI)

Neither "Attach to the most recently used window" nor "Attach to the most recently used window on this desktop" work for me on Windows 11. I am not using the Preview version of Windows Terminal. Any idea what's up?

MetaMmodern · 2022-02-13T10:55:54Z

For those who are kinda new to this: here is how you can do it the easy way.
1. Open Windows Terminal.

2. Open Settings.

3. Checkout this section in the startup menu.
   ![image](https://user-images.githubusercontent.com/42899786/153727389-56f004b6-cd7b-4b35-9531-ef2227e28638.png)

4. Select as I did.

5. Test by clicking "Open in Windows Terminal" elsewhere.
   Thanks Microsoft for adding this to GUI)
Neither "Attach to the most recently used window" nor "Attach to the most recently used window on this desktop" work for me on Windows 11. I am not using the Preview version of Windows Terminal. Any idea what's up?

Sorry, buddy, no idea. Try checking the above comments (like modifying the registry). I'll update my prev comment, cuz I'm on windows 10.

LawranceFung · 2022-02-13T21:37:07Z

Are there plans to launch a new tab in an existing window, but to choose the window based on MRU order?

zadjii-msft · 2022-02-14T11:40:06Z

choose the window based on MRU order?

that's... already how it's supposed to work?

LawranceFung · 2022-02-14T17:27:30Z

choose the window based on MRU order?

that's... already how it's supposed to work?

That's not working for me when calling
wt.exe -w 0 nt
or
wt.exe -w 1 nt
via AutoHotkey when both AutoHotkey and both Windows Terminal windows are running as administrator. It always opens the new tab in the first wt window opened.

DJackman123 · 2022-02-14T17:32:42Z

Wondering if that is related to #9628. Add this information to that bug so when it's evaluated for 1.14 this scenario will be included in that evaluation.

LawranceFung · 2022-02-14T17:37:42Z

Yes, should be same issue as #9628 barring some strange behavior when called by AHK.

Danthar added the Issue-Feature Complex enough to require an in depth planning process and actual budgeted, scheduled work. label Feb 5, 2020

ghost added Needs-Triage It's a new issue that the core contributor team needs to triage at the next triage meeting Needs-Tag-Fix Doesn't match tag requirements labels Feb 5, 2020

DHowett-MSFT added this to the Terminal Backlog milestone Feb 7, 2020

DHowett-MSFT added Area-Server Down in the muck of API call servicing, interprocess communication, eventing, etc. Product-Terminal The new Windows Terminal. labels Feb 7, 2020

ghost removed the Needs-Tag-Fix Doesn't match tag requirements label Feb 7, 2020

DHowett-MSFT removed the Needs-Triage It's a new issue that the core contributor team needs to triage at the next triage meeting label Feb 7, 2020

DHowett-MSFT changed the title ~~Allow remote applications to start a new shell inside an active WindowsTerminal instance~~ Allow remote applications to start a new shell inside an active WindowsTerminal instance (remote control?) Feb 7, 2020

DHowett-MSFT mentioned this issue Feb 14, 2020

Add "open Windows terminal here" into right-click context menu #1060

Closed

DHowett-MSFT mentioned this issue Feb 20, 2020

Add support for wt.exe to run commands in the current Terminal Window #4656

Closed

zadjii-msft changed the title ~~Allow remote applications to start a new shell inside an active WindowsTerminal instance (remote control?)~~ Add support for wt.exe to run commands in an existing Terminal Window Feb 20, 2020

zadjii-msft mentioned this issue Feb 20, 2020

MEGATHREAD: Commandline Args Follow-Up Work #4632

Open

40 tasks

zadjii-msft added the Area-Commandline wt.exe's commandline arguments label Feb 20, 2020

DHowett-MSFT mentioned this issue Feb 29, 2020

new-tab not working when running wt.exe from command line #4757

Closed

zadjii-msft mentioned this issue Mar 2, 2020

Command line argument to open new tab in existing window. #4764

Closed

DHowett-MSFT mentioned this issue Mar 3, 2020

wt split-pane & wt new-tab commands open a new window #4792

Closed

ranyitz mentioned this issue Mar 3, 2020

Support windows terminal ranyitz/newsh#13

Open

This was referenced Mar 10, 2020

Launch WSL terminals directly in Windows Terminal #4876

Closed

"wt split-pane" and "wt new-tab" commands always open a new window #4942

Closed

zadjii-msft mentioned this issue Mar 19, 2020

Open new terminal from cli as new tab on the already opened instance #5013

Closed

This was referenced Mar 22, 2020

Run another command prompt from the Windows terminal #5067

Closed

Open a new Terminal tab from command line (instead of a new console window) #5076

Closed

zadjii-msft mentioned this issue Apr 21, 2020

wt.exe commands open new Window #5442

Closed

zadjii-msft mentioned this issue Apr 19, 2021

Feature Request: CMD's "start" command should open new tab instead of new window #9867

Closed

skyline75489 mentioned this issue Apr 21, 2021

When Right Clicking to another folder or directory, it should add as a new tab not as a new window. #9912

Closed

zadjii-msft mentioned this issue Sep 7, 2021

Terminal hangs when opening new windows or new tabs on Windows Server 2022 #11135

Closed

This comment was marked as off-topic.

Sign in to view

zadjii-msft mentioned this issue Aug 30, 2022

Feature Request: Pop out Tabs and List Tabs on Taskbar #13879

Closed

This issue was closed.

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Add support for wt.exe to run commands in an existing Terminal Window #4472

Add support for wt.exe to run commands in an existing Terminal Window #4472

Danthar commented Feb 5, 2020

lostmsu commented Feb 6, 2020

DHowett-MSFT commented Feb 7, 2020

DHowett-MSFT commented Feb 7, 2020

zadjii-msft commented Feb 7, 2020

Future considerations

Rumbah2 commented Feb 14, 2020

mreymann commented Mar 12, 2021 •

edited

Loading

fredrikhr commented Mar 12, 2021

JenuelDev commented Apr 21, 2021

santanaruben commented Apr 21, 2021

androiddevnotes commented Aug 27, 2021

lfr commented Aug 30, 2021

zadjii-msft commented Aug 30, 2021

lfr commented Aug 30, 2021

zadjii-msft commented Aug 30, 2021

hardeepparmar commented Aug 30, 2021

zadjii-msft commented Aug 30, 2021

DJackman123 commented Aug 30, 2021

hardeepparmar commented Sep 1, 2021

MetaMmodern commented Feb 12, 2022 •

edited

Loading

LawranceFung commented Feb 13, 2022

MetaMmodern commented Feb 13, 2022

LawranceFung commented Feb 13, 2022

zadjii-msft commented Feb 14, 2022

This comment was marked as off-topic.

This comment was marked as off-topic.

LawranceFung commented Feb 14, 2022

DJackman123 commented Feb 14, 2022

LawranceFung commented Feb 14, 2022

Add support for wt.exe to run commands in an existing Terminal Window #4472

Add support for wt.exe to run commands in an existing Terminal Window #4472

Comments

Danthar commented Feb 5, 2020

Description of the new feature/enhancement

lostmsu commented Feb 6, 2020

DHowett-MSFT commented Feb 7, 2020

DHowett-MSFT commented Feb 7, 2020

zadjii-msft commented Feb 7, 2020

Future considerations

Rumbah2 commented Feb 14, 2020

mreymann commented Mar 12, 2021 • edited Loading

fredrikhr commented Mar 12, 2021

JenuelDev commented Apr 21, 2021

santanaruben commented Apr 21, 2021

androiddevnotes commented Aug 27, 2021

lfr commented Aug 30, 2021

zadjii-msft commented Aug 30, 2021

lfr commented Aug 30, 2021

zadjii-msft commented Aug 30, 2021

hardeepparmar commented Aug 30, 2021

zadjii-msft commented Aug 30, 2021

DJackman123 commented Aug 30, 2021

hardeepparmar commented Sep 1, 2021

MetaMmodern commented Feb 12, 2022 • edited Loading

LawranceFung commented Feb 13, 2022

MetaMmodern commented Feb 13, 2022

LawranceFung commented Feb 13, 2022

zadjii-msft commented Feb 14, 2022

This comment was marked as off-topic.

This comment was marked as off-topic.

LawranceFung commented Feb 14, 2022

DJackman123 commented Feb 14, 2022

LawranceFung commented Feb 14, 2022

mreymann commented Mar 12, 2021 •

edited

Loading

MetaMmodern commented Feb 12, 2022 •

edited

Loading