pass OSC7 and/or OSC9;9 info as profile "commandline" variable

[reardonia]

Description of the new feature/enhancement

Currently, WT supports the OSC9;9 escape sequence to set current-working-directory and uses that for local duplication of WSL, cmd, and Powershell sessions. It offers nothing for remote sessions, such as ssh.

Sidestepping the very long conversation at #12961 and elsewhere which attempts a perfect and standarized solution, it would be very helpful to propagate into an environment variable the info grabbed by WT from an OSC7 or OSC9;9 escape sequence. This ignores what WT should do internally during a "duplicate" and instead just allows for script or commandline mangling by skilled users.

A profile could then look like:
{ "commandline": "ssh.exe -t myname@myserver \" cd %WT_OSC9_9_PATH% ; bash --login \" ", ... }

See also the conversation from here:
#12961 (comment)

It's not possible today to clone remote ssh sessions and maintain the current-working-directory. Remote sessions to a single server are by far the most common case; tunneling and nested ssh sessions are relatively rare. There are edge cases pointed out exhaustively in #12961 and #3158, but this solution takes care of the common case and keeps WT from having to implement further hacks as was done for WSL.

Proposed technical implementation details (optional)

AFAICT, there is no support within WT to use environment variables or other state variables within a profile commandline. It may be valuable to broaden this feature to allow for other state variables to be passed into commandline.

One possible implementation is to use %WT_OSC7_PATH% and %WT_OSC9_9_PATH%

Either (1) add %WT_OSC7_PATH% and %WT_OSC9_9_PATH% to the environment when launching a duplicate profile or (2) make %WT_OSC7_PATH% and %WT_OSC9_9_PATH% and other state variables available when parsing profile commandline

[TBBle]

AFAICT, there is no support within WT to use environment variables or other state variables within a profile commandline. It may be valuable to broaden this feature to allow for other state variables to be passed into commandline.

I believe env-vars are expanded in the command-line, but before the Windows Terminal-specific env-vars (WT_*) or profile env-vars are added. And it looks like that ordering could be changed fairly easily, so exposing them as WT-specific env-vars and letting env-var expansion handle them seems like the lowest-hanging fruit.

---

I think that because we're already using OSC9;9 and expect Windows-path semantics from it except in very limited (hacky WSL) cases, this should be focused on OSC7 if we have to choose. However, OSC7 is a file:// URL, and for this use-case, turning that back into a POSIX path seems most-useful to make something like the following easy to recommend in docs, or include in a profile generator/profile snippet.

ssh.exe -t myname@myserver \"cd %WT_OSC7_PATH% ; exec ${SHELL}\"

wsl.exe -d Ubuntu-22.04 --cd %WT_OSC7_PATH%

These are the sort of use-cases I think this feature could enable, but there's still some rough edges there, e.g., what is the right value to use when we haven't received an OSC7 message? Use a POSIX-format startingDirectory value? Empty string and let the shell deal with the resulting nonsense?

[reardonia]

I think that because we're already using OSC9;9 and expect Windows-path semantics from it except in very limited (hacky WSL) cases, this should be focused on OSC7 if we have to choose. However, OSC7 is a file:// URL, and for this use-case, turning that back into a POSIX path seems most-useful to make something like the following easy to recommend in docs, or include in a profile generator/profile snippet.

ssh.exe -t myname@myserver \"cd %WT_OSC7_PATH% ; exec ${SHELL}\"

fwiw, ssh.exe would work even if %WT_OSC7_PATH% is empty. wsl.exe would not (it should accept --cd "" but it doesn't).