Starting directory no longer respected

[nphmuller]

Commit where this occurs: e0f131121b08dc5d6485e4bd985ac2c7e32b6339
Commit where this didn't occur yet: d5b8e7c32f7a419a7d467eab038251ee529056e6

Since the startingDirectory profiles.json setting was introduced (which is set to %USERPROFILE% by default), the current starting directory is no longer respected and the terminal always starts in %USERPROFILE%.

The startingDirectory setting is great to make sure the terminal doesn't always start in c:\windows\system32. It might however be better that its not used when starting Windows Terminal from a folder.

With starting WT from a folder I mean launching wt.exe (or wtd.exe) from an open cmd, or in Windows Explorer via its address bar.

The folder of the parent cmd process (or Explorer process) should then be used by default and startingDirectory should be used as a fallback. For example, when launching Windows Terminal from the start menu.

Steps to reproduce

• Make sure startingDirectory is set to %USERPROFILE%:

{
	...
	"profiles": [{
			"startingDirectory": "%USERPROFILE%",
		}, {
		...
		}
	],
	...
}

• Open an explorer window in a random folder (for example the root of the C drive)
• Type wt (or wtd) in the address bard

Expected behavior

Windows Terminal should open with the terminals path set to the folder opened in explorer. In the example this would be the root of the C drive: C:\.

Actual behavior

Windows Terminal opens with the terminals path set to the user profile path.

[DHowett-MSFT]

Oh, boy. You're totally right, this is a regression. It also breaks Scott Hanselman's "Open WT here" shortcut.

not used when starting Windows Terminal from a folder

So there's a problem. C:\Windows\System32 is a folder. I'd rather not detect "folders we care about" versus "folders we don't care about," as those two lists can get pretty long.

Maybe the right decision is to return {profile}.startingDirectory to being fully optional and revert parts of #604? @fghzxm will probably have an opinion here.

There's a split in user desire here: some people want the profile to indicate a starting directory, and some want WT to launch whatever profile you specify on the command line (#607) in the directory in which they start it. Hmm.

[nphmuller]

So there's a problem. C:\Windows\System32 is a folder.

Ah. Without checking how it actually worked, I kind of assumed it was detectable if the cmd (or other) process was launched directly vs if it was launched in a folder. But I guess since cmd.exe is in PATH its basically the same for the process and only the cwd differs.

Maybe the right decision is to return {profile}.startingDirectory to being fully optional and revert parts of #604?

I like the current default of startingDirectory being the home directory. But if I had to choose between either home directory vs cwd, I'd choose cwd. Of course its just my opinion though...

[fghzxm]

I think we can let wt.exe have a command line option

-p "P:\ath\to\some\directory"

and use that path for the starting directory, otherwise respecting the profile settings. This way you can type wt.exe -p . and get the behavior you want.
We probably should also have a look at how terminal emulators on other platforms behave in this aspect, but I think gnome-terminal always launches the shell in my home directory...

I don't think having 2 different behaviors depending on whether the parent process is cmd.exe, explorer.exe or some other is a good thing because

• The differing behaviors are confusing to the user, and
• The user could still launch wt.exe from msys2 bash, cygwin bash or any other alternative shell of which we would have to maintain a list that can never be exhaustive.

(Plus, I guess since Start now has its own process StartMenuExperienceHost.exe, the actual parent of the processes launched from Start will be that process instead?)

[nphmuller]

This way you can type wt.exe -p . and get the behavior you want.

Great solution! Maybe the the -p parameter can also be used as the default (unnamed) parameter.
That way we can even use wt.exe .. Which looks like the workflow many apps use (explorer ., code .)

I don't think having 2 different behaviors depending on whether the parent process is cmd.exe, explorer.exe or some other is a good thing because

Totally agreed. The solution you mentioned (-p) is simple and predictable.

[DHowett-MSFT]

We’ll have to converge with the people who want wt.exe cmd and wt.exe ssh example@example.com, plus the people who want wt.exe {profileguid}. Let’s talk about that in #607.

[fghzxm]

@nphmuller I would rather like to reserve the unnamed parameter for the profile name, which I think is more useful (of course this is up to personal tastes).