Consider using OSC 9;9 to inform Windows Terminal about CWD #11288

@skyline75489 commented on GitHub (Nov 5, 2020):

CC @Maximus5 for any suggestions on the remote connections.

@skyline75489 commented on GitHub (Nov 5, 2020): CC @Maximus5 for any suggestions on the remote connections.

claunia commented

@zadjii-msft commented on GitHub (Nov 5, 2020):

I owe you a longer writeup on both this and OSC 7, and now that I'm back from leave, I don't really have any excuses 😝 I'll try to write something up later today. Thanks for your patience!

@zadjii-msft commented on GitHub (Nov 5, 2020): I owe you a longer writeup on both this and OSC 7, and now that I'm back from leave, I don't really have any excuses 😝 I'll try to write something up later today. Thanks for your patience!

claunia commented

@skyline75489 commented on GitHub (Nov 6, 2020):

@zadjii-msft It's absolutely OK. Take you time, man.

I've been experimenting with ConEmu and OSC 9;9 sequences. From what I can tell, the result of a OSC 9;9 is an option in the "Startup directory" when creating a new console:

So yeah, I guess we could use it for #3158 without breaking the original meaning of the this sequence.

@skyline75489 commented on GitHub (Nov 6, 2020): @zadjii-msft It's absolutely OK. Take you time, man. I've been experimenting with ConEmu and OSC 9;9 sequences. From what I can tell, the result of a OSC 9;9 is an option in the "Startup directory" when creating a new console: ![image](https://user-images.githubusercontent.com/4710575/98322395-4693cb80-2022-11eb-837a-cd277ef3a735.png) So yeah, I guess we could use it for #3158 without breaking the original meaning of the this sequence.

claunia commented

@zadjii-msft commented on GitHub (Nov 9, 2020):

(copypasta from my comment in #7668)

This one doesn't seem that bad. Since it's a windows-first sequence, it doesn't need to know anything else about who's emitting the path. We can always assume it has been emitted as a Windows path. On the surface, this seems to work great, save for one scenario - ssh. This sequence doesn't accept any sort of hostname, it only takes the path. So if you were ssh'd into another machine, and that one emitted a OSC9;9, then there's no way of determining that sequence wasn't intended for the current machine.

I think I'm okay with us implementing this as-is for the time being though. It's not a perfect sequence, but it's good enough, and doesn't come with the compat baggage that OSC7 does. It can certainly be supported with the caveat "This won't work in an ssh session, or in any scenario where it's emitted by a remote connection. It will always be treated as a path on the local machine".

@zadjii-msft commented on GitHub (Nov 9, 2020): (copypasta from my comment in #7668) This one doesn't seem that bad. Since it's a windows-first sequence, it doesn't need to know anything else about who's emitting the path. We can always assume it has been emitted as a Windows path. On the surface, this seems to work great, save for _one_ scenario - ssh. This sequence doesn't accept any sort of `hostname`, it only takes the path. So if you were `ssh`'d into another machine, and that one emitted a `OSC9;9`, then there's no way of determining that sequence wasn't intended for the current machine. I think I'm okay with us implementing this as-is for the time being though. It's not a perfect sequence, but it's _good enough_, and doesn't come with the compat baggage that `OSC7` does. It can certainly be supported with the caveat "This won't work in an ssh session, or in any scenario where it's emitted by a remote connection. It will always be treated as a path on the local machine".

claunia commented

@skyline75489 commented on GitHub (Nov 9, 2020):

I think as a very Win32 specific sequence, I can understand why HOSTNAME does not exist in OSC 9;9: sshing into Win32 machines is simply not possible at the time the sequence was invented. And WSL was also not a thing.

Note that for most cases, it’s still good enough. We’ll always check the availability of the CWD before passing it to shell program, to make sure it actually exists on the local machine.

Having a working but not perfect solution is better than have nothing at all. Besides we can always extent OSC 9;9 as long as we align the movement with ConEmu in the future.

获取 Outlook for iOShttps://aka.ms/o0ukef

@skyline75489 commented on GitHub (Nov 9, 2020): I think as a very Win32 specific sequence, I can understand why HOSTNAME does not exist in OSC 9;9: sshing into Win32 machines is simply not possible at the time the sequence was invented. And WSL was also not a thing. Note that for most cases, it’s still good enough. We’ll always check the availability of the CWD before passing it to shell program, to make sure it actually exists on the local machine. Having a working but not perfect solution is better than have nothing at all. Besides we can always extent OSC 9;9 as long as we align the movement with ConEmu in the future. 获取 Outlook for iOS<https://aka.ms/o0ukef>

claunia commented

@Maximus5 commented on GitHub (Nov 9, 2020):

Just a couple of things to mention. From ConEmu perspective.

The "cwd" could be unix encoded (/mnt/c/path, /cyddrive/c/path, or simply /c/path) or Windows encoded (c:\path). And there are also network paths too... Depends on the shell emitting the sequence and settings.

It does not have much sense to check path existence upfront, we could have e.g. /c/users/admin on remote and localhost both.

In ConEmu the cwd is used not only for starting new shell, but also for processing "hyperlinks", such as produced in compilers errors output. ConEmu uses cwd to expand relative path. Interesting point here is that we could have in backscroll different points where cwd was changed (make was started from different folders). So it could be helpful if Terminal saves cwd for range of lines.

@Maximus5 commented on GitHub (Nov 9, 2020): Just a couple of things to mention. From ConEmu perspective. The "cwd" could be unix encoded (/mnt/c/path, /cyddrive/c/path, or simply /c/path) or Windows encoded (c:\path). And there are also network paths too... Depends on the shell emitting the sequence and settings. It does not have much sense to check path existence upfront, we could have e.g. /c/users/admin on remote and localhost both. In ConEmu the cwd is used not only for starting new shell, but also for processing "hyperlinks", such as produced in compilers errors output. ConEmu uses cwd to expand relative path. Interesting point here is that we could have in backscroll different points where cwd was changed (make was started from different folders). So it could be helpful if Terminal saves cwd for range of lines.

claunia commented

@TBBle commented on GitHub (Nov 9, 2020):

Apart from the path format (file:// URL vs potentially DOS-style path) and not having a 'hostname', what's the difference between this and OSC 7? Both notify of CWD, as I understand.

Is the advantage simply that we know a Windows-unaware program isn't going to generate this? And hence that if one needs to use cygpath or wslpath because one is in a virtualised-filesystem environment under Windows, then one sends the result via OSC 9;9 rather than OSC 7, and so Windows Terminal can implement only this, and leave OSC 7 unimplemented, as coming from a Windows-unaware shell and most-likely incorrect anyway.

Although ConEmu docs mentioned in the original ticket just send the locally-visible path out of WSL/Cygwin to OSC 9;9... It's not clear how that can work, perhaps it relies on something in the ConEmu cygwin/msys terminal connector, which means that OSC 7 and OSC 9;9 remain semantically the same, and WSL/Cygwin are still problematic.

@TBBle commented on GitHub (Nov 9, 2020): Apart from the path format (file:// URL vs potentially DOS-style path) and not having a 'hostname', what's the difference between this and OSC 7? Both notify of CWD, as I understand. Is the advantage simply that we know a Windows-unaware program isn't going to generate this? And hence that if one needs to use `cygpath` or `wslpath` because one is in a virtualised-filesystem environment under Windows, then one sends the result via OSC 9;9 rather than OSC 7, and so Windows Terminal can implement *only* this, and leave OSC 7 unimplemented, as coming from a Windows-unaware shell and most-likely incorrect anyway. Although [ConEmu docs mentioned in the original ticket](https://conemu.github.io/en/ShellWorkDir.html#connector-ps1) just send the locally-visible path out of WSL/Cygwin to OSC 9;9... It's not clear how that can work, perhaps it relies on something in the [ConEmu cygwin/msys terminal connector](https://conemu.github.io/en/CygwinMsysConnector.html), which means that OSC 7 and OSC 9;9 remain semantically the same, and WSL/Cygwin are still problematic.

claunia commented

@Maximus5 commented on GitHub (Nov 9, 2020):

I'm not sure when OSC7 appeared. The VT100 and xterm sequences does not have this code, and these standards I generally took into account implementing ConEmu parser.

Connector is not required to process the OSC9;9, ConEmu does not care who actually emits the cwd to terminal. On the other hand, without connector no ANSI is written to console, they are processed by cygwin1.dll. But Terminal should not care about it I believe. If sequence is emitted, terminal should note the cwd change.

@Maximus5 commented on GitHub (Nov 9, 2020): I'm not sure when OSC7 appeared. The VT100 and xterm sequences does not have this code, and these standards I generally took into account implementing ConEmu parser. Connector is not required to process the OSC9;9, ConEmu does not care who actually emits the cwd to terminal. On the other hand, without connector no ANSI is written to console, they are processed by cygwin1.dll. But Terminal should not care about it I believe. If sequence is emitted, terminal should note the cwd change.

claunia commented

@j4james commented on GitHub (Nov 10, 2020):

I'm not sure when OSC7 appeared. The VT100 and xterm sequences does not have this code

Yeah, XTerm doesn't support OSC 7. I believe it was originally developed by Apple for the OSX terminal app in 2011. I think VTE was next to support it in 2012, and over the years several other terminals have followed suit, including Mintty, Konsole, and iTerm2. Some of those terminals also had their own sequences for setting the directory, but they added OSC 7 support for compatibility. At this point, I'd probably consider it a de facto standard.

@j4james commented on GitHub (Nov 10, 2020): > I'm not sure when OSC7 appeared. The VT100 and xterm sequences does not have this code Yeah, XTerm doesn't support `OSC 7`. I believe it was originally developed by Apple for the OSX terminal app in 2011. I think VTE was next to support it in 2012, and over the years several other terminals have followed suit, including Mintty, Konsole, and iTerm2. Some of those terminals also had their own sequences for setting the directory, but they added `OSC 7` support for compatibility. At this point, I'd probably consider it a de facto standard.

claunia commented

@TBBle commented on GitHub (Nov 10, 2020):

To be clear, I wasn't trying to be critical of ConEmu for ignoring an existing standard etc.

What I'm really wondering is that given the ConEmu documentation suggests this for $PS1 in WSL:

if [[ -n "${ConEmuPID}" ]]; then
  PS1="$PS1\[\e]9;9;\"\w\"\007\e]9;12\007\]"
fi

and \w will be generating something like /home/myInWSLUser, how does that actually work for "Create new console"? This was one of the major issues in the OSC 7 discussion #7668, and since I'm not a ConEmu user, I'm interested to know if ConEmu had a solution for that.

I had expected to find it using something like:

if [[ -n "${ConEmuPID}" ]]; then
  PS1="$PS1\[\e]9;9;$(wslpath -m \"\w\")\007\e]9;12\007\]"
fi

@TBBle commented on GitHub (Nov 10, 2020): To be clear, I wasn't trying to be critical of ConEmu for ignoring an existing standard etc. What I'm really wondering is that given the ConEmu documentation suggests this for `$PS1` in WSL: ``` if [[ -n "${ConEmuPID}" ]]; then PS1="$PS1\[\e]9;9;\"\w\"\007\e]9;12\007\]" fi ``` and `\w` will be generating something like `/home/myInWSLUser`, how does that actually _work_ for "Create new console"? This was one of the major issues in the OSC 7 discussion #7668, and since I'm not a ConEmu user, I'm interested to know if ConEmu had a solution for that. I had expected to find it using something like: ``` if [[ -n "${ConEmuPID}" ]]; then PS1="$PS1\[\e]9;9;$(wslpath -m \"\w\")\007\e]9;12\007\]" fi ```

claunia commented

@skyline75489 commented on GitHub (Nov 10, 2020):

@Maximus5 Thanks for the reply. One thing I'd like to point out is that, we are mainly targeting #3158 as the primary usage of OSC 9;9.

It does not have much sense to check path existence upfront, we could have e.g. /c/users/admin on remote and localhost both.

Generally I get your point. But as I said we will mainly use the CWD to open new terminal tab in same directory. We don't really have an dialog to choose the starting directory, at least for now. In my initial implementation, the newly spawned shell will just arbitrarily use the CWD set by previous shells. This is why we want the CWD to be a valid local path (also why we take remote connections into consideration).

@TBBle The screenshot in my previous comment somewhat explains how it works. As far as I can see, ConEmu will not enforce users to use CWD to open new tabs. Instead it just adds an option in the dropdown. I guess this is one of the reasons why ConEmu is spared from the issues discussed in #7668.

@skyline75489 commented on GitHub (Nov 10, 2020): @Maximus5 Thanks for the reply. One thing I'd like to point out is that, we are mainly targeting #3158 as the primary usage of OSC 9;9. >It does not have much sense to check path existence upfront, we could have e.g. /c/users/admin on remote and localhost both. Generally I get your point. But as I said we will mainly use the CWD to open new terminal tab in same directory. We don't really have an dialog to choose the starting directory, at least for now. In my initial implementation, the newly spawned shell will just arbitrarily use the CWD set by previous shells. This is why we want the CWD to be a valid local path (also why we take remote connections into consideration). @TBBle The screenshot in my previous comment somewhat explains how it works. As far as I can see, ConEmu will not enforce users to use CWD to open new tabs. Instead it just adds an option in the dropdown. I guess this is one of the reasons why ConEmu is spared from the issues discussed in #7668.

claunia commented

@TBBle commented on GitHub (Nov 10, 2020):

Ah, thank you, I understand now. I hadn't realised "Create New Console" mentioned in the ConEmu docs had an intervening dialog before actually launching a new console.

@TBBle commented on GitHub (Nov 10, 2020): Ah, thank you, I understand now. I hadn't realised "Create New Console" mentioned in the ConEmu docs had an intervening dialog before actually launching a new console.

claunia commented

@zadjii-msft commented on GitHub (Nov 10, 2020):

and \w will be generating something like /home/myInWSLUser, how does that actually work for "Create new console"? This was one of the major issues in the OSC 7 discussion #7668, and since I'm not a ConEmu user, I'm interested to know if ConEmu had a solution for that.

I'd certainly be curious how that's supposed to work as well. I presumed that this was only being used for emit Windows-style paths for ConEmu. I'm okay with supporting this sequence, but only with the caveat "these paths must be the Windows relative path". If this isn't the typical usage, then it's certainly no better than OSC7.

Forcing the emitter to use Windows root-relative paths definitely puts the onus on the emitter to ensure that they're self-aware if they're running in WSL, cygwin, etc. It's not great, but for now it's better than OSC7 where the precedent has already been set that the emitter won't be aware of such scenarios.

As far as path validation goes, I'd start by treating this the same way wt -d c:\some\invalid\path works today. Maybe in the future, we could add some validation at the time we create the connection to check if the path exists (instead of just returning a [error 0x8007010b when launching 'cmd.exe']), but let's focus on the plumbing first IMO.

@zadjii-msft commented on GitHub (Nov 10, 2020): > and `\w` will be generating something like `/home/myInWSLUser`, how does that actually _work_ for "Create new console"? This was one of the major issues in the OSC 7 discussion #7668, and since I'm not a ConEmu user, I'm interested to know if ConEmu had a solution for that. I'd certainly be curious how that's supposed to work as well. I _presumed_ that this was only being used for emit Windows-style paths for ConEmu. I'm okay with supporting this sequence, but only with the caveat "these paths must be the Windows relative path". If this isn't the typical usage, then it's certainly no better than `OSC7`. Forcing the emitter to use Windows root-relative paths definitely puts the onus on the emitter to ensure that they're self-aware if they're running in WSL, cygwin, etc. It's not great, but for now it's better than OSC7 where the precedent has already been set that the emitter _won't_ be aware of such scenarios. <hr> As far as path validation goes, I'd start by treating this the same way `wt -d c:\some\invalid\path` works today. Maybe in the future, we could add some validation at the time we create the connection to check if the path exists (instead of just returning a `[error 0x8007010b when launching 'cmd.exe']`), but let's focus on the plumbing first IMO.

claunia commented

@Maximus5 commented on GitHub (Nov 12, 2020):

As far as I can see, ConEmu will not enforce users to use CWD to open new tabs. Instead it just adds an option in the dropdown.

That's almost true. User may configure task to use %CD% as task startup directory. I didn't make it default behavior, but think to do from time to time.

and \w will be generating something like /home/myInWSLUser

ConEmu can (at least should) do automatic translation of Unix path to Windows path to maintain PWD. But with /home folders it's problematic of course.
At some point it was not working, but now as I can see, starting wsl in the folders like \\wsl$\Ubuntu-18.04\home\maximus\myInWslUser and C:\SRC works properly.
So I tend to change \w into wslpath -m "\w" in docs for wsl.

@Maximus5 commented on GitHub (Nov 12, 2020): > As far as I can see, ConEmu will not enforce users to use CWD to open new tabs. Instead it just adds an option in the dropdown. That's almost true. User may configure task to use `%CD%` as task startup directory. I didn't make it default behavior, but think to do from time to time. > and `\w` will be generating something like `/home/myInWSLUser` ConEmu can (at least should) do automatic translation of Unix path to Windows path to maintain PWD. But with `/home` folders it's problematic of course. At some point it was not working, but now as I can see, starting wsl in the folders like `\\wsl$\Ubuntu-18.04\home\maximus\myInWslUser` and `C:\SRC` works properly. So I tend to change `\w` into `wslpath -m "\w"` in docs for wsl.

claunia commented

@TBBle commented on GitHub (Nov 12, 2020):

Quick note on wslpath -m, it's possible that there's no -m, and it needs to be -w. I know cygpath -m works for MSYS/Cygwin, but I don't recall if wslpath supports it.

It probably should be wslpath -w and cygpath -w for OSC 9;9 anyway, since the -m is "Windows path but with /", i.e. useful for appending to file://localhost/ to buld an OSC 7-valid URL.

@TBBle commented on GitHub (Nov 12, 2020): Quick note on `wslpath -m`, it's _possible_ that there's no `-m`, and it needs to be `-w`. I know `cygpath -m` works for MSYS/Cygwin, but I don't recall if `wslpath` supports it. It probably should be `wslpath -w` and `cygpath -w` for _OSC 9;9_ anyway, since the `-m` is "Windows path but with `/`", i.e. useful for appending to `file://localhost/` to buld an _OSC 7_-valid URL.

claunia commented

@3N4N commented on GitHub (Oct 15, 2021):

Has anyone managed to make it work for cmd? I was using pwsh with osc9;9 string, but pwsh was too slow for normal use and am thinking of using cmd for interactive use. But I cannot set it up to open the new tab/split in current directory. Help.

@3N4N commented on GitHub (Oct 15, 2021): Has anyone managed to make it work for cmd? I was using pwsh with osc9;9 string, but pwsh was too slow for normal use and am thinking of using cmd for interactive use. But I cannot set it up to open the new tab/split in current directory. Help.

claunia commented

@TBBle commented on GitHub (Oct 15, 2021):

https://gist.github.com/LuanVSO/09ba0239fe7c1a959a9b07c7156c5e13 from https://github.com/microsoft/terminal/issues/3158#issuecomment-802433664 might work. (I haven't tried it)

@TBBle commented on GitHub (Oct 15, 2021): https://gist.github.com/LuanVSO/09ba0239fe7c1a959a9b07c7156c5e13 from https://github.com/microsoft/terminal/issues/3158#issuecomment-802433664 might work. (I haven't tried it)

claunia commented

@3N4N commented on GitHub (Oct 16, 2021):

Yes, it works. The one I got before used OSC7 instead of 9;9.

@3N4N commented on GitHub (Oct 16, 2021): Yes, it works. The one I got before used OSC7 instead of `9;9`.

claunia commented

@TBBle commented on GitHub (Oct 16, 2021):

Yeah, OSC 7 isn't implemented in Windows Terminal, due to semantic conflicts in the specifications when applied to Windows.

@TBBle commented on GitHub (Oct 16, 2021): Yeah, `OSC 7` isn't implemented in Windows Terminal, due to semantic conflicts in the specifications when applied to Windows.

claunia commented

@joel-daros commented on GitHub (Oct 28, 2021):

EDIT:

Found a solution:
https://gist.github.com/LuanVSO/5e914af7f3f038f247b6729fc43b9c7c

I'm using Git Bash as default terminal in Window Terminal.
What is equivalent gist to put in .bashrc so that it remembers the last folder.

Already tried unsuccessful:

__wt_osc9_9 () {
    _win_path=$(pwd)
    printf "\033]9;9;%s\033\\" "$_win_path"
}

[ -n "$BASH_VERSION" ] && [ -n "$WT_SESSION" ] && PROMPT_COMMAND="__wt_osc9_9"

true

when terminal reopens it shows that error:

[error -2147024629 (-0x7ff8fef5) when launching `%USERPROFILE%/AppData/Local/Programs/Git/bin/bash.exe -l -i']
Could not access starting directory "/c/WINDOWS/system32"

@joel-daros commented on GitHub (Oct 28, 2021): **EDIT:** Found a solution: https://gist.github.com/LuanVSO/5e914af7f3f038f247b6729fc43b9c7c ------------------------ I'm using Git Bash as default terminal in Window Terminal. What is equivalent gist to put in .bashrc so that it remembers the last folder. Already tried unsuccessful: ``` __wt_osc9_9 () { _win_path=$(pwd) printf "\033]9;9;%s\033\\" "$_win_path" } [ -n "$BASH_VERSION" ] && [ -n "$WT_SESSION" ] && PROMPT_COMMAND="__wt_osc9_9" true ``` when terminal reopens it shows that error: ``` [error -2147024629 (-0x7ff8fef5) when launching `%USERPROFILE%/AppData/Local/Programs/Git/bin/bash.exe -l -i'] Could not access starting directory "/c/WINDOWS/system32" ```

claunia commented