You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
After updating Windows Terminal, pressing Ctrl+Profile will not inherit the working directory #15173
In the first stable version that supports creating an administrator profile window by holding down Ctrl (Version 1.15.2525.0), its behavior was as expected. After Windows Store updated Windows Terminal recently, I found that its behavior was broken.
Currently I can only solve this behavior change by using the powershell -Command Start-Process wt -Verb runAs command, but it is very inconvenient.
I just tested every stable version and found that 1.15.3465.0 and 1.15.3466.0 are the last stable versions that can inherit the working directory, while 1.16.10261.0 and 1.16.10262.0 are the first stable versions that will not inherit the working directory.
Also noticed this when looking into #14817 and in my case I was not able to set the working directory for ShellExecute. Somehow it was never talking into account and googling around didn't return anything useful.
Hmm. I bet this especially breaks in 1.18. I wonder actually if "startingDirectory": "." will be really broken, because the Terminal's CWD will always be the CWD of the first terminal window.
Okay, I've got a possible solution, but I think I ended up building it on top of #5506, and that might be too much to pull in this late in the release.
Basically, the simple idea is:
Manually pass the evaluated CWD to _OpenElevatedWT,
so that we launch elevate-shim new-tab -p {guid} -d <path>.
That'll then ShellExecute({ "shell:AppsFolder\...", "new-tab -p {guid} -d <path>"}),
and then the elevated window would treat that as "manually start this profile with the CWD <path>"
I deeply worry that'll cause mysterious edge cases with like, c:\ or other string escaping nonsense.
Mike Griese (@zadjii-msft) you marked this up for 1.17 servicing but it has a hard dependency on the virtual CWD work. Do you think we should backport them as a pair, or would you be willing to retool the fix to be 1.17-specific?
In version 1.17 Preview, the working directory inheritance was restored, but in the recent update to version 1.18, it broke again. What happened? 🤔 Mike Griese (@zadjii-msft)
Activity
TGSAN commentedon Apr 13, 2023
In the first stable version that supports creating an administrator profile window by holding down Ctrl (Version
1.15.2525.0), its behavior was as expected. After Windows Store updated Windows Terminal recently, I found that its behavior was broken.Currently I can only solve this behavior change by using the
powershell -Command Start-Process wt -Verb runAscommand, but it is very inconvenient.TGSAN commentedon Apr 13, 2023
I just tested every stable version and found that
1.15.3465.0and1.15.3466.0are the last stable versions that can inherit the working directory, while1.16.10261.0and1.16.10262.0are the first stable versions that will not inherit the working directory.DHowett commentedon Apr 13, 2023
Mike Griese (@zadjii-msft) hm.
ShellExecute("appsfolder:...")fallout?zadjii-msft commentedon Apr 18, 2023
probably
kovdu commentedon Apr 26, 2023
Also noticed this when looking into #14817 and in my case I was not able to set the working directory for
ShellExecute. Somehow it was never talking into account and googling around didn't return anything useful.1.15.2525.0is just doingCreateProcessWhere https://github.com/microsoft/terminal/blob/release-1.15/src/cascadia/ShellExtension/OpenTerminalHere.cpp#L47 but was not starting elevated then.So indeed moving to
ShellExecuteis causing this. But don't know what would the best way to set the working directory then tbh.zadjii-msft commentedon May 1, 2023
Hmm. I bet this especially breaks in 1.18. I wonder actually if
"startingDirectory": "."will be really broken, because the Terminal's CWD will always be the CWD of the first terminal window.Butts.
zadjii-msft commentedon May 1, 2023
Okay, I've got a possible solution, but I think I ended up building it on top of #5506, and that might be too much to pull in this late in the release.
Basically, the simple idea is:
_OpenElevatedWT,elevate-shim new-tab -p {guid} -d <path>.ShellExecute({ "shell:AppsFolder\...", "new-tab -p {guid} -d <path>"}),<path>"I deeply worry that'll cause mysterious edge cases with like,
c:\or other string escaping nonsense.This works for #15173, but no me gusta
zadjii-msft commentedon May 1, 2023
note:
did not just work
This works for #15173, but no me gusta
Manually pre-evaluate the starting directory when calling elevate-shim (
DHowett commentedon May 15, 2023
Mike Griese (@zadjii-msft) you marked this up for 1.17 servicing but it has a hard dependency on the virtual CWD work. Do you think we should backport them as a pair, or would you be willing to retool the fix to be 1.17-specific?
Manually pre-evaluate the starting directory when calling elevate-shim (
zadjii-msft commentedon May 17, 2023
Dustin L. Howett (@DHowett) Uh, maybe there's a way to retool. The vCWD work is definitely too scary to backport straight to Stable
TGSAN commentedon Jun 30, 2023
In version 1.17 Preview, the working directory inheritance was restored, but in the recent update to version 1.18, it broke again. What happened? 🤔 Mike Griese (@zadjii-msft)