wt.exe from command line with named console binary picks the wrong tab icon and wrong tab title

[pstaag]

Environment

Windows build number: Microsoft Windows [Version 10.0.19041.450]
Windows Terminal version (if applicable): 1.2.2381.0

Steps to reproduce

start Windows terminal from console or Run... with a chosen named .exe that produces console output.

eg. win+R wt thiscommandisjustanexample enter

(picking a binary that actually does exist is not making a difference for this bug)

Expected behavior

• Tab gets it's title from the binary's name

• Tab gets it's icon from the called binary / tab gets a generic console-binary icon, since the binary does not contain one

Actual behavior

The tab inherits several pieces of behaviour from the default profile.

This includes,

• the icon that is defined for defaultProfile in settings.json
• the tabTitle that is defined for defaultProfile in settings.json
• the default profile's backgroundImage with it's settings for backgroundImageStretchMode and backgroundImageAlignment applied as defined in settings.json

Reflection

You are just applying the default profile to anything unknown that runs, don't you?

Awesome. In that case, I guess, Windows Terminal requires a hidden default profile that is invoked if nothing else applies. Instead of just picking the one that is opened as default on start.

[KalleOlaviNiemitalo]

It looks like Windows Terminal does not attempt to use the icon and title of the command at all. I have Git Bash as the default profile, and if I run wt cmd, then Windows Terminal starts cmd.exe in the Git Bash profile and gets the icon and title from that profile. I can override the title with a command like wt --profile "Command Prompt" --title "nslookup" nslookup but cannot get the command-specific icon.

In the console host (cmdhost.exe or openconsole.exe), SystemConfigurationProvider::GetSettingsFromLink tries to find an icon and a title for the console window. If it later becomes possible to set Windows Terminal as the default terminal in Windows (#492, #7414), then it would make sense for Windows Terminal to choose the icon and title in a similar way. (If a user just runs wt thiscommandisjustanexample, then there is no .lnk file involved, and many features of that function cannot be used.)

What is wrong with using the background image of the default profile?

[pstaag]

@KalleOlaviNiemitalo I use profile specific backgrounds. One for Debian, one for PoweShell, and so on.

Calling wt.exe with a console binary in Windows and getting Debian's logo (because Debian is my default profile) on it...something does not sit right with me about that.

It's not the bug that will hinder Windows Terminal from shipping, but it's also Not Right^tm

[KalleOlaviNiemitalo]

Perhaps wt command and wt new-tab command should choose the profile this way:

1. If the -p or --profile option is given, use that.
2. Otherwise, if commandProfile is defined in settings.json, use that. This would be a new setting. It could refer to a hidden profile. The name of the commandProfile setting would not depend on command.
3. Otherwise, if defaultProfile is defined in settings.json, use that.
4. Otherwise, use the first profile.

commandProfile would not be used for plain wt or wt new-tab without command.

That would solve the background image issue but would still not use a command-specific icon and title.

[DHowett]

So, this is going to become more important once we land #492. The solution we're going to go with in the interim is...

• If there is a defaults block (profiles.defaults), apply that to any applications started up by the default terminal interface.

I don't think we can generally grab icons from whatever you launch (without grovelling in the process tree to figure out whose executable is on the hook for running a given commandline), but we can definitely fall back to a default icon. Perhaps we should do the process tree thing.

When we apply this change to commandline invocation (which I do think we should), there will be a split between -p x command and command invocation, just like there should have been.

After we land that, we can talk about process name matching. ConEmu supports taking over as the default terminal on Windows, and it lets you specify "when x.exe is running, my profile is y". We should absolutely have something similar.

After that, we can hook up default mappings (any cmd.exe => Command Prompt unless hidden, any pwsh.exe, powershell.exe => a powershell profile).

[DHowett]

As a workitem that's going to require nontrivial work and design discussion even though its outward appearance is that of a bug, this is going to be one of our rare "task-bugs".

[DHowett]

/cc @miniksa this is topical for your recent defterm investiation

[zadjii-msft]

I may xlink this to #1504, #9458, #4768. This might just be a dup of that trio.

[zadjii-msft]

Note
for discussion:

We probably want to document what we want to do here, since this isn't the defeterm scenario. We'll use #14372 for the "defterm" version. This thread might turn into something like:

wt --icon foo.exe -- foo.exe

or something like, "When icon is null for a profile, use the commandline's application's icon as the icon". That assumes that we can parse out the application from the commandline, but I think we already do that. Might need discussion.

[zadjii-msft]

Hmm. This is... trickier than it might seem on the surface. Cause here's the thing - we almost always get the tab icon from the profile directly. That's right. So in the profiles.defaults + commandline case, we don't really keep the original commandline around.

Goddard, options:

• We persist the icon as a part of the Pane, and then get the icon out of the active pane, rather than the profile of the pane.
• We persist the icon as a part of the TerminalSettings / TermControl. This is the same as the first, but with more plumbing (for a future where clients could like, set their own icon (Suggestion: ability for terminals to set their tab icon #1868))
• We persist the NewTerminalArgs as a part of the Pane. There's been discussion of this before, in Duplicating a tab/pane without a valid profile should still duplicate the settings from that tab #5047.
  • Though, in that thread, we actually decided it would be best to build up a new NewTerminalArgs from the current settings of the Pane, rather than stashing the original.
  • So that sounds kinda like option 1

Okay so option 1 - put the icon in the pane. Follow-up problem: now, when the settings reload, we have to re-use that commandline to rebuild what the icon for the pane should be. Barf.

[zadjii-msft]

I bet after #15843, if you set the icon of the profiles.defaults to null, then wt -- foo.exe might just auto pick the icon of foo.exe

Nope, no, it won't. It'll still try to pick the icon of the profile, because we still don't do the NewTerminalArgs propagation thing. We're literally asking for the Profile of the pane, and getting the icon from the profile. Not from the TerminalSettings or anything like that.

[NewtonChutney]

I hope we solve the issue of icon picking differences between conhost and wt!
conhost nu and wt nu