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

Documentation Issue - "Source" = "Windows.Terminal.Wsl" #4103

New Issue
Closed
opened 2026-01-30 23:38:04 +00:00 by claunia · 9 comments
claunia commented 2026-01-30 23:38:04 +00:00
Owner
Copy Link

Originally created by @fpqc on GitHub (Sep 27, 2019).

There is a new feature that appears to automatically generate profiles based on existing WSL distributions.

image

I tried messing around with these automatically-generated profiles, and it looks like you can add additional parameters to them, but if you change the GUID, they are regenerated automatically, so I assume there is a hidden GUID associated with each WSL installation.

However, when I used the wsl.exe -h, I couldn't find a way to verbosely print the GUID, although I assume it's stored somewhere in the registry.

This "Source" feature as well as the specific profile generator "Windows.Terminal.Wsl" should probably be documented.

For instance, I would like to be able to pass the ~ parameter, which tells wsl to launch in the Linux user's $HOME. Is there a way to pass that parameter to the profile generator? Can we build our own profile generators?

Originally created by @fpqc on GitHub (Sep 27, 2019). There is a new feature that appears to automatically generate profiles based on existing WSL distributions. ![image](https://user-images.githubusercontent.com/6083371/65738178-e1f50600-e0d8-11e9-8ecf-6342fccd7be5.png) I tried messing around with these automatically-generated profiles, and it looks like you can add additional parameters to them, but if you change the GUID, they are regenerated automatically, so I assume there is a hidden GUID associated with each WSL installation. However, when I used the wsl.exe -h, I couldn't find a way to verbosely print the GUID, although I assume it's stored somewhere in the registry. This "Source" feature as well as the specific profile generator "Windows.Terminal.Wsl" should probably be documented. For instance, I would like to be able to pass the `~` parameter, which tells wsl to launch in the Linux user's $HOME. Is there a way to pass that parameter to the profile generator? Can we build our own profile generators?
claunia added the Needs-TriageResolution-Fix-CommittedNeeds-Tag-FixIssue-Docs labels 2026-01-30 23:38:04 +00:00
claunia commented 2026-01-30 23:38:05 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Sep 27, 2019):

There is a bit of documentation here:
https://github.com/microsoft/terminal/blob/master/doc/user-docs/UsingJsonSettings.md#dynamic-profiles

and then quite a bit more here (warning, this is a feature spec so it's more technical implementation details):
https://github.com/microsoft/terminal/blob/master/doc/specs/%23754%20-%20Cascading%20Default%20Settings.md#dynamic-profiles

We probably should add notes to the first doc that the GUID of dynamic profiles should not be changed, and if you do they'll be re-generated.

The Windows Terminal generates those guids itself. We generate them in a stable fashion, using the distro's name, so anyone with an "Ubuntu 18.04" profile will have the same GUID for that profile.

If you want the starting directory to be ~, I'd recommend adding "startingDirectory": "\\\\wsl$\\<distroname>\\home\\<your wsl username>" to the profile.

There's not really a way to add your own generators at this time, though we are keeping our eye on them as a part of the future extensibility model.

@zadjii-msft commented on GitHub (Sep 27, 2019): There is a bit of documentation here: https://github.com/microsoft/terminal/blob/master/doc/user-docs/UsingJsonSettings.md#dynamic-profiles and then quite a bit more here (warning, this is a feature spec so it's more technical implementation details): https://github.com/microsoft/terminal/blob/master/doc/specs/%23754%20-%20Cascading%20Default%20Settings.md#dynamic-profiles We probably should add notes to the first doc that the GUID of dynamic profiles should not be changed, and if you do they'll be re-generated. The Windows Terminal generates those guids itself. We generate them in a stable fashion, using the distro's name, so anyone with an "Ubuntu 18.04" profile will have the same GUID for that profile. If you want the starting directory to be `~`, I'd recommend adding `"startingDirectory": "\\\\wsl$\\<distroname>\\home\\<your wsl username>"` to the profile. There's not really a way to add your own generators at this time, though we are keeping our eye on them as a part of the future extensibility model.
claunia commented 2026-01-30 23:38:05 +00:00
Author
Owner
Copy Link

@fpqc commented on GitHub (Sep 27, 2019):

If you want the starting directory to be ~, I'd recommend adding "startingDirectory": "\\\\wsl$\\home\\<your wsl username>" to the profile.

Does this work even if multiple distros are running?

Edit: Yeah, you have to include the distro name

"\\\\wsl$\\<Distro Name>\\home\\<your wsl username>"

Okay, that's nice! Is there a way to append a command as a parameter like

"wsl.exe tmux new-session -A -s main"

in the generated profile, something like a "launchWithCommand" option in the json?

@fpqc commented on GitHub (Sep 27, 2019): > If you want the starting directory to be ~, I'd recommend adding "startingDirectory": `"\\\\wsl$\\home\\<your wsl username>"` to the profile. Does this work even if multiple distros are running? Edit: Yeah, you have to include the distro name `"\\\\wsl$\\<Distro Name>\\home\\<your wsl username>"` Okay, that's nice! Is there a way to append a command as a parameter like `"wsl.exe tmux new-session -A -s main"` in the generated profile, something like a "launchWithCommand" option in the json?
claunia commented 2026-01-30 23:38:06 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Sep 27, 2019):

Oh good catch. That's what I get for replying on the internet before coffee 😝

You can always just change the "commandline" of the generated profile. Only the GUID and source need to remain unchanged for us to be able to find the match.

@zadjii-msft commented on GitHub (Sep 27, 2019): Oh good catch. That's what I get for replying on the internet before coffee 😝 You can always just change the "commandline" of the generated profile. Only the GUID and source need to remain unchanged for us to be able to find the match.
claunia commented 2026-01-30 23:38:06 +00:00
Author
Owner
Copy Link

@fpqc commented on GitHub (Sep 27, 2019):

Also, I deleted the builtin profiles for cmd, powershell, and Azure just now to see if they got automagically regenerated, and only Azure got regenerated. But here's the weird thing: cmd and powershell still appear in the list of possible shells and work fine. What's going on here? Is this some old hardcoded behavior of the profile generator for those two examples? I'm now afraid that if I change their GUIDs then I'll have duplicates.

@fpqc commented on GitHub (Sep 27, 2019): Also, I deleted the builtin profiles for cmd, powershell, and Azure just now to see if they got automagically regenerated, and only Azure got regenerated. But here's the weird thing: cmd and powershell still appear in the list of possible shells and work fine. What's going on here? Is this some old hardcoded behavior of the profile generator for those two examples? I'm now afraid that if I change _their_ GUIDs then I'll have duplicates.
claunia commented 2026-01-30 23:38:06 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Sep 27, 2019):

I mean, I'd just go read the rest of the doc, especially this section: https://github.com/microsoft/terminal/blob/master/doc/user-docs/UsingJsonSettings.md#settings-layering

Basically, the cmd/powershell profiles are just "default profiles". They always exist. If you want to truly delete them, you'll need to add "hidden":true to them.

Same thing applies though, if you change their guid in your profiles.json, there will still be two that show up at runtime, though only one in your actual file.

@zadjii-msft commented on GitHub (Sep 27, 2019): I mean, I'd just go read the rest of the doc, especially this section: https://github.com/microsoft/terminal/blob/master/doc/user-docs/UsingJsonSettings.md#settings-layering Basically, the cmd/powershell profiles are just "default profiles". They always exist. If you want to truly delete them, you'll need to add `"hidden":true` to them. Same thing applies though, if you change their guid in your `profiles.json`, there will still be two that show up at runtime, though only one in your actual file.
claunia commented 2026-01-30 23:38:07 +00:00
Author
Owner
Copy Link

@fpqc commented on GitHub (Sep 27, 2019):

Here's the problem: I lost their GUIDs because i accidentally closed my editor. I now can't edit them at all because their GUIDs are lost to the void (I assume they have the same GUIDs as on my laptop, so I can copy them from there, but this is a bad solution). The profiles did not get regenerated.

I didn't intend to hide them or whatever, I was testing profile auto-regeneration =(.

@fpqc commented on GitHub (Sep 27, 2019): Here's the problem: I lost their GUIDs because i accidentally closed my editor. I now can't edit them at all because their GUIDs are lost to the void (I assume they have the same GUIDs as on my laptop, so I can copy them from there, but this is a bad solution). The profiles did not get regenerated. I didn't intend to hide them or whatever, I was testing profile auto-regeneration =(.
claunia commented 2026-01-30 23:38:07 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Sep 27, 2019):

You can just hold alt while clicking on "settings" to open the defaults.json file and get them from there.

@zadjii-msft commented on GitHub (Sep 27, 2019): You can just hold <kbd>alt</kbd> while clicking on "settings" to open the `defaults.json` file and get them from there.
claunia commented 2026-01-30 23:38:07 +00:00
Author
Owner
Copy Link

@fpqc commented on GitHub (Sep 27, 2019):

Ah, I see.

The spec says that there should be a profile generator called

"Microsoft.Terminal.PowershellCore".

Is it safe to assume there is also one called

"Microsoft.Terminal.Cmd"?

Do these work if we plug them in as

"source": "Microsoft.Terminal.PowershellCore"

and mutatis mutandis for "Microsoft.Terminal.Cmd"?

@fpqc commented on GitHub (Sep 27, 2019): Ah, I see. The spec says that there should be a profile generator called `"Microsoft.Terminal.PowershellCore"`. Is it safe to assume there is also one called `"Microsoft.Terminal.Cmd"`? Do these work if we plug them in as `"source": "Microsoft.Terminal.PowershellCore"` and mutatis mutandis for `"Microsoft.Terminal.Cmd"`?
claunia commented 2026-01-30 23:38:07 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Sep 27, 2019):

Nope, the cmd and powershell.exe (windows powershell) profiles are hard-coded, they don't come from a generator.

Basically anything in your user settings is "layered" upon anything that's in the default.json file. Hence why you no longer need to have each and every keybinding in your profiles.json anymore, or why the Powershell profile is blue despite not having a backgroundColor set in (a new) profiles.json

We can assume safely that Windows Powershell and cmd exists on every machine the Terminal runs on, hence why they're defaults like this. The other "dynamic" profiles - wsl, powershell core, those we can't expect so much.

@zadjii-msft commented on GitHub (Sep 27, 2019): Nope, the cmd and powershell.exe (windows powershell) profiles are hard-coded, they don't come from a generator. Basically anything in your user settings is "layered" upon anything that's in the `default.json` file. Hence why you no longer need to have each and every keybinding in your `profiles.json` anymore, or why the Powershell profile is blue despite not having a backgroundColor set in (a new) `profiles.json` We can assume safely that Windows Powershell and cmd exists on _every_ machine the Terminal runs on, hence why they're defaults like this. The other "dynamic" profiles - wsl, powershell core, those we can't expect so much.
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-Docs Needs-Tag-Fix Needs-Triage Resolution-Fix-Committed
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#4103
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?