Open new terminal tab in same directory as existing tab (OSC 7?)

[edencorbin]

Description of the new feature/enhancement

Have the option (or default) of a new terminal tab opening in the current directory of the window of which you hit the hotkey to open a new tab. This is the standard way most linux terminals work and is most handy. I often work in a directory where I need to launch multiple seperate processes, its a pain to CD back into the directory each time.

Proposed technical implementation details (optional)

Hit the new tab hotkey, the new terminal should then be in the same folder as the previouse.

---

maintainer edit: Before commenting, make sure to check out

Tutorial: Opening a tab or pane in the same directory in Windows Terminal

This is largely something configurable today, this issue is just tracking another way of configuring this

[egmontkob]

There's a "standard" escape sequence (OSC 7 ; URI ST) to set the terminal emulator's belief about the current directory. It originates from macOS Terminal.app, and was later adopted by some other ones, including GNOME Terminal and as far as I know Konsole too.

Another possible approach is to do some OS-specific hacks to examine the inner state of the child process (or even further down to descendents).

Yet another possibility is to mix the two, e.g. go to the directory set via OSC 7 if it was ever emitted, otherwise dig into the process.

The advantage of the OSC 7 approach is that it's clever regarding when to and when not to follow a child process. E.g. you start another nested subshell, it'll be the subdirectory of that subshell that's taken into account because that one also emits this sequence. However, launch an app that internally changes directory (e.g. make) and it – luckily – won't be make's internal subdir that's used.

The disadvantage of OSC 7 is that it requires cooperation from the shell, or other apps that matter.

[DHowett-MSFT]

I've been rejecting this feature request for as long as this project has been open-source, and I never learned about OSC 7. This is very exciting.

I'm not happy to crawl through the process tree to dig up the leafmost process's CWD, but I am extremely happy to support OSC 7.

[davidhewitt]

FYI I asked about OSC 7 handling for Alacritty, which eventually led to this issue being created in the "Terminal WG" on gitlab: https://gitlab.freedesktop.org/terminal-wg/specifications/issues/20

There's not been much movement on that ticket, but you may be interested to follow it. Especially if you guys have any opinions regarding what a "formal" specification for OSC 7 might look like.

[zadjii-msft]

So for the record, the thread at alacritty/alacritty#2937 has a pretty great discussion.

Honestly, I'm pretty okay using the de-facto standard that's already in place, the OSC 7 ; <URI> ST mechanism. I'm not really sure there needs to be anything more formal than that.

---

Wait no I had a terrible thought. Say bash is configured to emit that, and someone runs bash in WSL. What are we supposed to do when someone tries to set the working directory to /home/zadjii? How we:

1. tell that this is a WSL path, not a Windows path
2. know which WSL distro this came from?

Do we need to add some property on our side that indicates "this is a WSL distro, not a Windows exe"? What happens to users who don't set that, does the duplicate tab functionality just not work (effectively silently)?

Then the next part gets harder. What happens when this command is output over SSH? The terminal can't know that the path isn't on this machine anymore, right? How does Terminal.app handle this?

Maybe this does need more specification 😨

[egmontkob]

(Off: How long is it going to be until I mix up the two of you, D Howett and D Hewitt? :))

[slikts]

This is a crucial missing feature.

[anthonyvdotbe]

This should be a config option for the different commands. For example, I'd like this for duplicateTab and splitPane, but not for newTab.

[LuanVSO]

the escape sequence is documented in mac os terminal.app preferences as shown by this comment alacritty/alacritty#2937(comment)

On macOS, the escape sequences are actually specified in Terminal.app > Preferences... > Profiles > Tab

[zadjii-msft]

For the record, there's heated debate over in https://gitlab.freedesktop.org/terminal-wg/specifications/merge_requests/7 about the specification of exactly this feature. I doubt that we'll support any subset of this feature until there's an actually accepted proposal there - we'd rather not introduce another disparate implementation until there's an actual standard.

[egmontkob]

I'd recommend you to do the opposite :)

Quite a few terminals have successfully implemented OSC 7, copying from each other, resulting in happy users.

And there is somebody out there currently who thinks it isn't good enough, he thinks a formal specification is needed; comes up with a draft that is full of problems, and what I cannot understand at all, is only willing to document one of two siblings. (Note: I stopped following that thread a couple of days ago.)

Terminal-WG is not a formal authority, its documents aren't "official", aren't "standards" in any de jure way. It doesn't even have proper procedures, people with responsibilities, voting rights, whatever; no one knows what it takes to get a document "accepted" there, whatever this status means at all. It's just a collection of random unorganized folks trying to come up with something useful. Don't let those unofficial pending debates stop you from implementing a long-proven feature.

[LuanVSO]

For the record, there's heated debate over in https://gitlab.freedesktop.org/terminal-wg/specifications/merge_requests/7

i commented it on the issue referenced in that pr too 😉

[alkorlos]

Thank you!

Important clarification — I did not do anything unusual, on the contrary, yesterday I performed a clean installation of Ubuntu 22.04.2 LTS.
After a clean install, I installed only nvm. After that of the files listed here: .bash_profile, .bash_login, .profile, only exists .profile. File .bash_profile I created, as it was written here. In addition to the problem with nvm, there was a problem with colors, but I did not betray this.

Indeed, adding PROMPT_COMMAND to the .profile and deleting .bash_profile helped.

Thanks again! Cheers!

[TBBle]

Okay, so it might make sense to add a note to the docs along the lines of "If .bash_profile does not exist, but .profile does, add the line there instead", to avoid confusion for the default Ubuntu 22.04 setup and any similar situations.

The current instructions do not say to create the file, but in this situation, it's a reasonable guess that happens to do the wrong thing.

I note the MINGW instructions use .bashrc instead, which won't have this problem. That's maybe a better choice, as it's specifically for interactive shells, IIUC.

[daviewales]

The creator of powerlevel10k has created a Zsh plugin for this.
He claims it "...achieves the same thing as the code snippet in the official Windows Terminal documentation but with fewer bugs and better performance".

Linking it here for visibility:
https://github.com/romkatv/windows-terminal-zsh-integration

[TBBle]

I don't know the zsh ecosystem, but is that plugin widely-suitable-enough to be added as a preferred option to the Windows Terminal docs?

It's clearly too-long to inline into the docs (and is doing a lot more than the one-liner does, such as caching, some TMUX-specific magic and for some reason using wslpath -am and mangling the output rather than wslpath -w), but if general zsh users can do an extra git clone over the current docs and get a much better result, then it seems like an easy win to me.

If zsh plugin managers are commonly used, then that's even better, IMHO.

The main concern I envisage is making the docs dependent on an external site.

[Asterikss]

In regard to comments made by alkorlos and TBBle.
This might help somebody in the future:

• TL;DR:
  • remove potential "cd ~" or "cd ~/my-preferred-starting-dir" from .bashrc
  • remove .bash_profile if using .profile (then move PROMPT_COMMAND to .profile or .bashrc)

1. On a few forums on the Internet it is advised to put "cd ~" or some variation of this in .bashrc to change the starting directory. This can be overlooked and will obviously make PROMPT_COMMAND not produce the desired result.

2. If you did not have .bash_profile and you created it, as it was written here, PROMPT_COMMAND will work, given you put it in .bash_profile, however this will also "skip" your "config" (.bashrc and .profile). .bashrc is not "loaded" by default. .profile is responsible for that, but it is also not always "loaded".

First few lines of .profile:

# ~/.profile: executed by the command interpreter for login shells.
# This file is not read by bash(1), if ~/.bash_profile or ~/.bash_login
# exists.

Solutions:

• copy the contents of .profile to .bash_profile. e.g.

...
# if running bash
if [ -n "$BASH_VERSION" ]; then
    # include .bashrc if it exists
    if [ -f "$HOME/.bashrc" ]; then
	. "$HOME/.bashrc"
    fi
fi

# set PATH so it includes user's private bin if it exists
if [ -d "$HOME/bin" ] ; then
    PATH="$HOME/bin:$PATH"
fi

# set PATH so it includes user's private bin if it exists
if [ -d "$HOME/.local/bin" ] ; then
    PATH="$HOME/.local/bin:$PATH"
fi
...

or

• remove .bash_profile and put PROMPT_COMMAND in either .profile or .bashrc

[deadcoder0904]

why is this not implemented even 5 years later?

i don't think this is unreasonable for any web developer working on a project that requires to spin up >2 scripts in the same directory.

[zadjii-msft]

Well, I mean, it has and it hasn't.

You've been able to use shell integration to open a new tab/pane in the same CWD for a couple years now, using OSC9;9. (osc9;9 was originally tracked in #8166) This thread is technically tracking a similar escape sequence, OSC7, which we haven't had a chance to come back around on yet (because it's got some trickier edge cases with WSL distros). #8214 (linked earlier in this thread) has some of the most complete discussion on the whole problem space.

Alas, automagic CWD detection (like linux) will almost certainly never work, as some shells (cough powershell) don't actually set their CWD.

Then there's of course the potential for automatically modifying people's prompts, such that shell integration is automatically enabled for them. This is definitely something that I want to investigate going forward, maybe sometime next year. But I doubt that'll work for everyone or every shell.

[ewlondon]

I know this is an old topic but I just wanted to say for anyone trying to get split panes to same directory using GitBash in 2024, adding this line to .bashrc finally worked for me. The previously listed command by JahzVH was not working correctly for me and would give an error ping every time a prompt was input into terminal.

PROMPT_COMMAND=${PROMPT_COMMAND:+"$PROMPT_COMMAND "}'printf "\e]9;9;%s\e\\" "$(cygpath -w "$PWD")"'

[Daydreamer-riri]

Hi @zadjii-msft , you mentioned shell integration which works fine in Powershell, but when I configure my wsl / zsh using the method described in it, the root directory still opens when I split the pane. I'm trying to understand if I'm missing something?

[TBBle]

@Daydreamer-riri I'd suggest checking what settings are used to launch WSL. I don't know if it's still the default, but IIRC it used to default to including a path on the command line (so it wouldn't start in C:\Windows\System32), and that would override the path provided by this feature.

Also worth checking if you haven't already that nothing else in your zsh startup scripts are changing the current directory, e.g., see point 1 of #3158 (comment).

For example, this Ubuntu WSL config block works for me with the bash setup from the shell integration docs:

            {
                "guid": "{2c4de342-38b7-51cf-b940-2309a097f518}",
                "hidden": false,
                "icon": "C:/Program Files/WindowsApps/CanonicalGroupLimited.UbuntuonWindows_2004.2022.1.0_x64__79rhkp1fndgsc/Assets/Square44x44Logo.altform-unplated_targetsize-256.png",
                "name": "Ubuntu",
                "source": "Windows.Terminal.Wsl",
                "startingDirectory": "//wsl$/Ubuntu/home/paulh"
            },

If changing the startingDirectory value changes the start directory successfully, then your zsh startup scripts are not overriding the directory set by this feature, at least, as that's the value this feature overrides.

[Daydreamer-riri]

‌‌Hi @TBBle, the settings in my Terminal are:

I found something interesting: when I use the former (which is, the source is Windows.Terminal.Wsl), the path can be duplicate correctly. But it is hidden by default and the latter is used by default. The latter cannot duplicate the path correctly. Is this perhaps a bug?

[TBBle]

Try adding a manual commandLine to the non-working profile, something like C:\Windows\System32\wsl.exe -d Ubuntu-24.04. I don't know what command line that dynamic profile source is actually providing on your machine, but my guess it it hard-codes the starting directory in some way. (You could also try adding a startingDirectory value to it (~ should work), since the Windows.Terminal.Wsl profile source generates one by default, but that shouldn't make a difference, and my research below suggests that it's the command-line.)

Anyway, I did some more digging: I have a different Ubuntu build installed (CanonicalGroupLimited.UbuntuonWindows_2004.2022.1.0_x64__79rhkp1fndgsc) but I checked its snippet (with this process), and it apparently just runs ubuntu.exe, which does (or at least used to) override startingDirectory and hence is incompatible with this feature, so I'm fairly confident this is the problem.

If you confirm that adding a commandLine entry fixes the starting directory, then it's an issue specific to the Ubuntu-provided snippets (or a behaviour choice in their ubuntu.exe launcher, probably the false in this line, which was inherited from MS's template launcher project originally implemented by a familiar author) and you would need to raise it as a ticket with them to fix in some way. You're welcome to link or quote this comment in any such issue you raise.

Edit: Gah. Turns out we already have a bug in this repo for this issue, #12961, which provides a simpler commandLine value to use: ubuntu run. That possibly should be the default command in the Ubuntu snippet... along with startingDirectory value ~ as used by the WSL profile generator. So still an Ubuntu issue to fix, but not a difficult one.

---

In short, I think this will work to fix your issue: In the second profile, add the following two lines to the start:

"commandLine": "ubuntu.exe run",
"startingDirectory": "~",

[Daydreamer-riri]

‌‌Thank you very much for your survey. It's incredible to have accomplished so much work in such a short time.

However, after I added these two lines to the configuration, everything behaved the same as before, with no improvement.

[zadjii-msft]

Did you set "commandline"? or "commandLine"? (note the capital L)

The setup from the docs Works On My Machine when I don't use the profile that Canonical provides, and use the built-in WSL profiles instead:

Using the canonical profile: ("commandline": "ubuntu2204.exe")

Using the built-in dynamic profile: ("commandline": "C:\WINDOWS\system32\wsl.exe -d Ubuntu-22.04")

[Daydreamer-riri]

‌‌‌I have not set up "commandline". The configuration was automatically generated after installing WSL:

{
    "colorScheme": "Chester",
    "guid": "{acbafd15-cbbb-5bb3-8a61-bed446ff4b83}",
    "hidden": false,
    "name": "Ubuntu 24.04 LTS",
    "opacity": 95,
    "source": "CanonicalGroupLimited.Ubuntu24.04LTS_79rhkp1fndgsc"
}

When I set the source to Windows.Terminal.Wsl, the documentation works.

[TBBle]

Yes, that works because by changing the source, you're changing the profile you're inheriting from Ubuntu's one, to the built-in profile that includes the two lines I shared. If you do that, you may as well just unhide the actual profile generated by Windows Terminal, and hide the Ubuntu-generated one, to avoid any risk of confusion in-future. (If you go this way, you can add Ubuntu to the list of profile generators to ignore, and then remove that generated profile entirely, for a cleaner config file.)

Can you share the version of that profile with the two lines I provided added, that wasn't working, so if we can see if there's anything else needed?

I expect this should work, is that what you had?

{
    "commandLine": "ubuntu2204.exe run",
    "startingDirectory": "~",
    "colorScheme": "Chester",
    "guid": "{acbafd15-cbbb-5bb3-8a61-bed446ff4b83}",
    "hidden": false,
    "name": "Ubuntu 24.04 LTS",
    "opacity": 95,
    "source": "CanonicalGroupLimited.Ubuntu24.04LTS_79rhkp1fndgsc"
}

[Daydreamer-riri]

Yes, that works because by changing the source, you're changing the profile you're inheriting from Ubuntu's one, to the built-in profile that includes the two lines I shared. If you do that, you may as well just unhide the actual profile generated by Windows Terminal, and hide the Ubuntu-generated one, to avoid any risk of confusion in-future. (If you go this way, you can add Ubuntu to the list of profile generators to ignore, and then remove that generated profile entirely, for a cleaner config file.)

Can you share the version of that profile with the two lines I provided added, that wasn't working, so if we can see if there's anything else needed?

I expect this should work, is that what you had?

{
    "commandline": "ubuntu2204.exe run",
    "startingDirectory": "~",
    "colorScheme": "Chester",
    "guid": "{acbafd15-cbbb-5bb3-8a61-bed446ff4b83}",
    "hidden": false,
    "name": "Ubuntu 24.04 LTS",
    "opacity": 95,
    "source": "CanonicalGroupLimited.Ubuntu24.04LTS_79rhkp1fndgsc"
}

Sorry, the configuration you provided works, the reason I said it didn't work before was because I filled in the name of the executable wrong (my ubuntu version is 2404 but I wrote 2204). The only problem with it now is that my wsl default directory becomes my Windows user directory instead of the user directory in wsl.

When I set commandline to wsl.exe -d Ubuntu-22.04:

[TBBle]

Ah yeah, sorry about getting the number wrong. I originally typed "2004" out of habit, and fixed it looking at the example in the other ticket, not your settings. >_<

Anyway, I'd go with the wsl.exe -d Ubuntu-22.04 command-line setting then. That should be all the launcher is doing underneath, after the first-run setup anyway.

Otherwise, you can also put your real desired startup directory in the startingDirectory parameter, e.g., you can see in my earlier example I use //wsl$/Ubuntu/home/paulh which is /home/paulh inside the Ubuntu WSL install. If you navigate to \\wsl$ in Windows Explorer, you should be able to get the correct path to use by browsing in there, but I assume it'll be something like \\wsl$\Ubuntu-2404\home\<yourWSLAccountName>. (My use of / is probably legacy here and only works with wsl.exe, \-based paths like you'd copy from Explorer should work, but remember to double the backslashes if you're editing the JSON directly. I just changed mine to use \ and it works fine.) Easier method: Go into the directory in WSL that you want to be your starting directory, and run wslpath -w "$PWD". Put that in your config; if you're editing JSON directly, double the backslashes.

Sadly, it turns out Windows Terminal makes the ~ starting directory work by specifically looking for wsl.exe on the command line and otherwise turns it into USERPROFILE as you have discovered. There's a separate hack that specifically looks for the source Windows.Terminal.Wsl (used for drag-and-drop support AFAICT, see #17691) so clearly some outstanding work to be done to make this all work nicely out-of-the-box for WSL profiles/launchers other than the built-in default WSL profile generator.

[Daydreamer-riri]

Thank you! Thanks for your guidance.

I think it should be stated in the documentation that “Opening a tab or pane in the same directory” requires some extra work when using the default generated "source": ‘CanonicalGroupLimited... profile”.

Hopefully this will help more people.

[TBBle]

I think it should be stated in the documentation that “Opening a tab or pane in the same directory” requires some extra work when using the default generated "source": ‘CanonicalGroupLimited... profile”.

The problem is the "source": ‘CanonicalGroupLimited... profile” is not part of Windows Terminal, so I'd suggest you raise a suggestion with the project providing that source (https://github.com/ubuntu/WSL) to change it to work "better", or better-document the effect their profile has on Windows Terminal, and any extra steps the user needs to take to make it work.

There's some work that could be done in Windows Terminal, but it wouldn't be Ubuntu-specific and would require coordination with any such WSL distributions in their profile contributions too.

[Lyton505]

Hi @Daydreamer-riri mentioned CanonicalGroupLimited.Ubuntu_79rhkp1fndgsc being faulty. I am also observing the same behaviour. How did you change it to Windows.Terminal.Wsl Whenever I try to change it in settings.json, I get the following error:

Could not find your default profile in your list of profiles - using the first profile. Check to make sure the "defaultProfile" matches the GUID of one of your profiles.