Terminal: Documentation Issue - "Source" = "Windows.Terminal.Wsl"

[fpqc]

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

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?

[zadjii-msft]

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.

[fpqc]

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?

[zadjii-msft]

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.

[fpqc]

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.

[zadjii-msft]

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.

[fpqc]

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 =(.

[zadjii-msft]

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

[fpqc]

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"?

[zadjii-msft]

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.