Terminal: Feature Request: Option to open new tabs in the same directory as the current tab

[dallonf]

Summary of the new feature/enhancement

Very often when I'm working on a project, I want to open multiple tabs in the same directory. For example, for a web React project, I might want one tab for npm start, another for npm test --watch, and probably keep another around for various console commands I want to run (like git). It'd be very convenient to cd into my project directory and then just hit Ctrl-T a few times to open up more tabs in that project directory.

Instead, each tab current seems to be opened in the normal "startingDirectory", which is %USERPROFILE% by default, so you have to cd into the desired working directory for every new tab.

[DHowett-MSFT]

This is a "hard problem".. Technically, Terminal can't know the working directory of the process hosted inside it. This will be easier with #1131, but still "hard" for shells that don't actually _set_ the working directory. PowerShell, for example, doesn't set the working directory!

[Jaykul]

Yeah, I always set the working directory in my PowerShell prompt function, because I can't understand why it doesn't do that on it's own ...

But certainly it's tricky or impossible when some tabs are going to be purely remote (e.g. azshell).

Maybe a solution would be to have a command line that could be run to start a new tab, and which would therefore know which directory it was running in?

[DHowett-MSFT]

On account of this one isn't possible in the general sense (for all types of connections, and all types of applications), I'm going to close it out. Sorry.

[jarrodek]

This is disappointing. As a person with Linux background staring a new tab in a directory of previously selected tab is a normal thing. When working on a project I often need 2-3 tabs running stuff from the project. For a developer UX I would reconsider how to incorporate this behavior.
I am trying to switch from Ubuntu to Windows for some time now and the only blocker left is usable console which is at leas as good as Bash. I don't feel that current release is as close.

[FXschwartz]

Same as @jarrodek I'm coming from a Linux background trying to make the 100% switch to Windows.

Really the only thing that was keeping me from it was the console. This new console is so far incredible and makes me super excited for the future of developing on Windows.

Being able to

1. Open a console
2. Go to the working project directory
3. Duplicate tab (with directory path) multiple times

is something I do multiple times daily.

Obviously, not a deal-breaker but would be absolutely incredible to have.

[dallonf]

What are some ways this could work in a narrow use case? I'm personally fine if I can't duplicate an ssh tab or something like that, but for the common case of having a cmd/PowerShell/WSL terminal open and just wanting another one, it'd be very useful.

[davidhewitt]

Also coming from a linux background, it's very helpful to be able to quickly open console tabs in the same directory. (It's disruptive to thinking to have to cd to some folder far from the terminal default when you want to briefly run a new command while some other long-lived command is running in your existing terminal.)

I understand it can't work in all cases, but I'd love to contribute a PR where the existing ctrl+shift+d shortcut can preserve the working directory in cases where Terminal can detect the working directory.

Only blocker to me submitting that PR is it doesn't seem obvious to me how to inspect the current working directory of a child process using the Windows APIs (equivalent of Linux's /proc/<PID>/cwd)! If anyone is able to suggest a method to me for that bit, I would happily do the rest.

[zadjii-msft]

I'd certainly review a PR that enabled this :)

I remain worried that this will not work more often than it will work, but if we have a prototype, then it'll certainly be easier to make the call.

Unfortunately, I don't really know how to get the working dir of another process myself. Presumably there must be a way... @DHowett-MSFT thoughts?

[rigwild]

Any news on this ? This feature would be really useful.

[zadjii-msft]

@rigwild I'd follow #3158 - that issue actually has a bit more detail on how such a feature might actually be possible to implement, so we've been using that one to track this feature.