New Tab should launch in the original starting directory

[jacob-pro]

Windows Terminal version

1.12.10982.0

Windows build number

10.0.19043.1706

Issue

I am stuck between two bad options for the starting directory option:

Launched From	Expected	Starting Directory .	Starting Directory %USERPROFILE%
"Open in Terminal" Context Menu	The folder you are currently in	✓	✓
Entering wt -d . in the explorer address bar	The folder you are currently in	✓	✓
Start menu / task bar shortcuts	$USERPROFILE directory	✘ System32	✓
Clicking new tab	The folder the first tab launched in	✓	✘ %USERPROFILE%

In short, the new tab behaviour works as expected when the "Use parent process directory" option is enabled, however I can't use this option because it breaks the start menu shortcuts (#11834 and #878)

Background

The use-case for this is that I often want to right click a folder to open in terminal, this opens in my default shell (e.g. WSL), but sometimes I actually want to be using a different shell in this directory (Powershell).

Or another example: I'm developing a project in C:\Users\jacob\projects\example, I want to right click open in terminal, and then have multiple tabs for running different tasks in the project

[lhecker]

There's another option: You can use "Duplicate Tab" (Ctrl+Shift+D) to duplicate the current tab including its starting directory.

[AltitudeApps]

I like to use:

wt --window 0 new-tab -d .

to start a new tab, and have it be in the same directory that the first tab is in.

wt -w 0 nt -d .

is a shortcut for the same thing. It's always in my command history, so I just use 'up-arrow' to find it.

[jacob-pro]

Thanks @lhecker, but the problem is that I often don't want to duplicate the tab, since I would like to swap to a different shell.

[AltitudeApps]

@jacob-pro
I think I now I see what you mean.

If I have my profiles set to "Use parent process directory", things work well, except for the fact that invoking Terminal from the start menu now drops me into C:\Windows\System32. (Which is rather nostalgic.) Both C:\Windows\System32 and %USERPROFILE% meet the criteria of "almost NEVER where I want to be", so I had never noticed that being dropped into C:\Windows\System32 was inconvenient, because %USERPROFILE% is just as inconvenient for me. But I can see how System32 would be pretty irritating if you mostly needed to be in %USERPROFILE%.

However, aside from the above issue, I am able to launch a new tab into a shell of my choice, in a directory that makes sense for the current session, by using the following command (which is itself a bit inconvenient, admittedly):

wt --window 0 --profile 'Command Prompt'

Perhaps more convenient is that clicking the profile selection dropdown in Terminal and choosing a shell from there also drops me into the expected directory. (Meaning the directory that this wt.exe window was originally launched in.)

In other words, by starting the session by right-clicking on the 'directory of the day' in Windows Explorer, and choosing "Open in Terminal", things will get set up such that all other tabs opened via the Terminal GUI controls in that particular window will open in that same directory.

Launching a different shell in the same directory via a command:

Launching a different shell in the same directory via the GUI:

[jacob-pro]

Yep exactly @AltitudeApps if you have "Use parent process directory" set then new tabs work as expected, and as a bonus you can also run wt.exe in your explorer address bar without the -d . hack.

IMO "Use parent process directory" is how it should work by default, because that is how all other shells on Windows - cmd.exe, powershell.exe normally work.

But as I already noted this breaks the start menu / task bar shortcuts, since they seem to default to System32. Normally (if this was any Win32 application) I would just create a custom shortcut with the right starting directory set, but this doesn't work properly for Windows Apps: #12996 (comment)

[DHowett]

But as I already noted this breaks the start menu / task bar shortcuts, since they seem to default to System32.

Honestly that's like 95% of why we added startingDirectory in the first place. It remains atrocious that applications launched by "PLM" (the "Package Lifetime Manager" or whatever) start in System32.

We tried to fix it at one point, but it turned out to be even worse than we thought. You can see the damage in Mike's comment here: #3547 (comment), detailed description section.

[jacob-pro]

@DHowett IMHO you should have merged that PR to open in the working directory by default, that makes almost everything work how it is expected by developers, and is consistent with CMD/Powershell, basically any other shell application.

Leave the Start Menu & Taskbar shortcuts opening in System32 problem to the Microsoft Windows team - since it is their silly problem to fix 😆 - All they need to do is give us the ability to modify the start menu shortcut to have a custom working directory, just like the shortcuts for powershell and cmd already do.

[michael-hawker]

There's another option: You can use "Duplicate Tab" (Ctrl+Shift+D) to duplicate the current tab including its starting directory.

Hmm, I was expecting when I duplicated the tab for it to bring me to the current directory that I was in on that tab...

If I wanted to be in the starting directory, I'd just open a new tab with that profile right?

[jacob-pro]

@michael-hawker I don't think that is technically viable, since Windows Terminal supports all sorts of shells (cmd, mingw bash, wsl etc.) and there is no way / standard API for them to communicate back what directory they are currently in

[michael-hawker]

@jacob-pro interesting, there's a discussion about it for #10232, so I wonder what they're thinking there?

[zadjii-msft]

There actually totally is a standard way for the shell to tell the terminal about the CWD. There's no good way for the Terminal to ask, but the client app can tell the terminal. See Tutorial: Opening a tab/pane in the same directory in Windows Terminal

[zadjii-msft]

Ultimately, I don't think we're about to change the base behavior here. However, reading between the lines a little, the bit that gets me is:

Launched From	Expected	Starting Directory .	Starting Directory %USERPROFILE%
Clicking new tab	The folder the first tab launched in	✓	✘ %USERPROFILE%

That's probably a pretty unique workflow, tbh, but I think there's another request on the backlog that might address it: #445. With the proposal in that thread, you'd be able to rebind the action of the new tab button. So, you could change it from just newTab to a newTab action, with the startingDirectory changed to .:

"newTabButton":
{
  "command": { "action": "newTab", "startingDirectory": "." }
}

That's probably the way I'd go about solving this, at least. I'd go upvote that thread as a potential solution here.