-
Notifications
You must be signed in to change notification settings - Fork 8.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Change Windows OS to support default terminal [defterm] #492
Comments
This is by design. We have plans to support setting another application as the "default terminal" on Windows, but those plans are still very rough and in the works. |
This will require an OS feature. I'm updating the title to represent the default terminal OS change. |
I'm renaming this to add the |
I hope this gets added sooner rather than later, are there any working unofficial workarounds? |
Rest assured that this issue would have had hundreds of community comments making up all sorts of crazy workarounds if there were any ;) |
I have a idea for some basic bat file:
|
I have been starting cmd (and now powershell) from Win+R for decades, but I am painfully retraining myself to type wt instead. I guess you can teach an old dog new tricks. Slowly. 😁 This works thanks to the app execution alias wt.exe in %userprofile%\AppData\Local\Microsoft\WindowsApps |
Hi team, users, since wt has now very good set of options and a preset settings json and a user defineable part which also includes the setting, which console is the default console to be opened when launching wt - I thought it would be sufficient to pick up all the rough plans (#492 (comment)) to pick up at least the following attempt: Integration of Win+X. How I think you can accomplish this:
like Settings > Personalisation > Taskbar "replace Win+X cmd with powershell" Maybe it is a naive point of view of a user, yet I cannot imagine that it is possible to switch cmd to Powershell at this point for years now, but not making the small step forward to replace these two items again with wt. And yes it would make sense this way having wt with and without admin rights, as per default it is also unelevated like every other console (with few exceptions) Can you please elaborate why this is so much work to do? It would be a beginning. Having the choice of a default terminal application in Settings > Apps and Features > Default app - I can understand this requires more under the hood work. I double checked with NirSoft ShellExView that this can not be that easily achieved at the moment. However changing the Win+X setting mentioned above is already something that is there. You can find the tool here but use at your own risk Hope I am allowed to post this reference otherwise please remove it. If I may upload the app as a zip or Onedrive please let me know. There is no hint that it is not allowed to mirror it elsewhere. |
p.s. I've tried myself to Add wt into a new group in Win+X menu but for some unclear reason it fails to do so. Permissions seem about right. I can add any file as a link except things from I am curious what prevents this by design. It seems because the apps there are 0 kb sized files and some kind of symlink? In Task Manager you also cannot "open the location" of a wt process. I suspect this is the nature of app virtualization of MS apps. Also applies to other like Edge Chromium, notepadS etc. Given this information and circumstances I might now grasp why it is so hard to accomplish this change. You cannot access it from explorer, but you can launch it from Win+R / search. How weird. |
You can't add wt.exe directly, as it's not a "real file", but if you create a shortcut to wt.exe, the tool will be able to add it and it'll work just fine. You can read more about it here: https://www.hanselman.com/blog/TotallyUnsupportedHacksAddWindowsTerminalToTheWinXShortcutMenu.aspx |
If I understand the function of WinX correctly Windows does not do links by path only, probably to prevent spoofing but also generating a hash of the file. Since all "apps" have zero filesize the "cannot open" might be due to not being able to generate the hash, probably not because not being able to access / read it. Thanks for the reference thlac @shanselman this makes it even harder to understand why there is no official way. Ofc having a shortcut to a file exposes a risk of tampering it, what seems to contradict the original design idea of WinX not being easily tampered. |
@Karl-WE Just wanted to make sure everyone is on the same page here. Windows Terminal is a terminal/console application - not a shell. Cmd and PowerShell are shells. (See also: https://www.hanselman.com/blog/WhatsTheDifferenceBetweenAConsoleATerminalAndAShell.aspx) So the Win+X setting is (IMHO) irrelevant for this issue (as it just determines the shell, not the terminal application). |
I understand your definition. At the end, given the many same requests, WinX does help to make Windows Terminal
Seeing it in this light, I still agree with your noted difference but in the end the goal is to help making a shell easier to access while having the better features of terminal compared to the default console. |
@nu8 you’ll probably agree that “replacing your system conhost with the version of conhost built out of this repository” and “having Windows launch an instance of Terminal automatically” are vastly different things ;) This repository hosts both the console host and the Terminal. One builds on the other, but they are certainly not the same. |
@nu8 given the vast amount of things @DHowett has to review and triage sometimes there maybe differences. As you quoted it is clear that 492 in timeline came before 1817 and things can change. the good news is: it is on the schedule, no longer in the backlog see 1 | Default terminal | If a command-line application is spawned, it should open in Windows Terminal (if installed) or your preferred terminal source: https://github.com/microsoft/terminal/blob/master/doc/terminal-v2-roadmap.md |
@DHowett thank you for your work around here, I have a small question: |
We're the team that would have to do the OS-level work to enable this feature, so I'd be very surprised if we weren't aware of work being done to enable this. We're still just getting past the 1.0 release of the Terminal, so we haven't really gotten a start on this quite yet. I'd say it's unlikely to land in 20H2 or 21H1, considering we'd probably have to have the feature done (or at least prototyped) by now to get it in to either of those releases. |
This comment has been minimized.
This comment has been minimized.
Because this issue has so many subscribers, I'm going to lock it. |
- Implements the default application behavior and handoff mechanisms between console and terminal. The inbox portion is done already. This adds the ability for our OpenConsole.exe to accept the incoming server connection from the Windows OS, stand up a PTY session, start the Windows Terminal as a listener for an incoming connection, and then send it the incoming PTY connection for it to launch a tab. - The tab is launched with default settings at the moment. - You must configure the default application using the `conhost.exe` propsheet or with the registry keys. Finishing the setting inside Windows Terminal will be a todo after this is complete. The OS Settings panel work to surface this setting is a dependency delivered by another team and you will not see it here. ## Validation Steps Performed - [x] Manual adjust of registry keys to the delegation conhost/terminal behavior - [x] Adjustment of the delegation options with the propsheet - [x] Launching things from the run box manually and watching them show in Terminal - [x] Launching things from shortcuts and watching them show in the Terminal Documentation on how it works will be a TODO post completion in #9462 References #7414 - Default Terminal spec Closes #492
This issue tracks the work required to add "default terminal" support to Windows.
This is not terminal-specific, but Windows Terminal will benefit from it.
original content
This bug-tracker is monitored by Windows Console development team and other technical types. We like detail!
If you have a feature request, please post to the UserVoice.
Please use this form and describe your issue, concisely but precisely, with as much detail as possible
Your Windows build number:
Microsoft Windows [Version 10.0.18885.1001]
What you're doing and what's happening: When I type
start
in a command prompt session in the Windows Terminal, the new command prompt window opens in a new conhost window.What's wrong / what should be happening instead: The new command prompt should open in a new tab in the existing Terminal window.
The text was updated successfully, but these errors were encountered: