Other options for overriding profile starting directory

[krage]

Description of the new feature/enhancement

The new command line arg for specifying starting directory is great but it's limited to individual panes and tabs created during launch. I'd like additional ways of specifying starting directories for panes/tabs, particularly those that get created after launch. Here's two additions I think would be useful:

Window-wide starting directory command line argument

Starting a terminal with wt --windowStartingDirectory "c:\my\project\dir" would cause all tabs/panes opened during the life of that terminal window to start in c:\my\project\dir. This is useful for opening a terminal window directly in a deeply nested project directory and then quickly and easily opening/closing additional panes/tabs in that location. This should also apply to all panes/tabs created via initial command line args that don't have an individual --startingDirectory specified.

You can more or less achieve this right now by setting a profile's starting directory to . and starting wt.exe itself with the actual desired starting directory as working directory. However this requires a more complicated launch, eg. cmd /C start /D "c:\my\project\dir" wt. You also lose the ability to keep a useful default starting directory in the profile's settings for a simple launch of wt.exe.

newTab and splitPane keybind options for reusing current directory

An additional option for the newTab/splitPane keybindings could open these with starting directory set to the current working directory of the current tab/pane. Useful if you open a terminal, eventually cd to some directory, and then want additional panes/tabs in that directory.

---

These would be additions to a prioritized list where the tab/pane being created uses the highest priority starting directory that was provided, eg:

1. reuse current directory via keybind
2. --startingDirectory command line argument
3. --windowStartingDirectory command line argument
4. profile starting directory
5. wt.exe working directory

[DHowett-MSFT]

For newTab and splitPane, that's tracked by #3158. For windowStartingDirectory, I'm not sure I agree that Terminal should be the arbiter here: it seems like the issue is more correctly solved by fixing #878 (it's closed, but I do not know how I feel about that) or setting the startingDirectory in all your profiles to null (which is easily doable with the defaults key) and then simply starting WT in the desired directory. It's never going to be perfect, but neither is a big-hammer global override switch.

I'm concerned about the veritable pandora's box of features that opens up as well: if we can override startingDirectory at an app level for all profiles started under a window, why not padding? background image? But then, why have a profile system at all?

This likely warrants further discussion. 😄

[krage]

I hadn't seen #3158 when I was looking around, that appears to cover newTab and splitPane.

I think you're right adding windowStartingDirectory as a global override of profile-specific settings would be an overreach and potentially confusing.

The startingDirectory behavior I'm kind of emulating is tmux usage where there are various means of controlling the working directory of a session both at and after launch. With terminal I have all of my profiles' startingDirectory set to "." (the provided json schema warns if I specify a non-string and this seems to work for inheriting terminal's working directory, though it appears null also works as you suggest). I find the ergonomics currently aren't great though in both lacking a configurable default and necessitating launching via cmd.exe/powershell.exe etc. to specify a working directory in various other circumstances.

For defaults, just launching from the standard shortcut in start menu / task bar uses c:\windows\system32 (virtually never useful to me) whereas typing wt in the windows run dialog starts in %USERPROFILE% (better, but not the default I actually want). I'm not actually sure if there's a clean way to change the working directory used when launching via task bar at all. I can create my own shortcut to %USERPROFILE%\AppData\Local\Microsoft\WindowsApps\wt.exe, give that a starting directory and pin it to the task bar... but terminal instances unfortunately aren't grouped under that taskbar icon.

Maybe a better approach that still covers what I'm hoping for would be an optional defaultWorkingDirectory in the global settings that could be overridden by an optional --workingDirectory command line arg?

[waahoo]

In Ubuntu, when I press ctrl+alt+T, the terminal will launch at user home. Additionally, I can launch the terminal at current directory by context menu "Open in terminal. I would like windows terminal can do the same whether or not by overriding profile starting directory. That is "launch from task bar will be at user home` and context menu for current directory".

[zadjii-msft]

@waahoo you might be interested in #878. Specifically, this: #878 (comment), and the PR #3547, and the investigation that was done in that PR.

[zadjii-msft]

Copying my post from #9991, which was basically the same thing

What if we had something like:

{
    "ignoreStartingDirectories": bool,
}

as a global setting? Then we'd just never use the startingDirectory for a profile, and always use the CWD of the Terminal. That seems like a big hammer, but there might be folks who are all setting "startingDirectory": "." for all their profiles, where this would be an easier solution.

Alternatively: What about wt --cwd C:\foo new-tab? That would make sure that the Terminal's CWD is set to C:\foo, not just the CWD of that tab. That would work better for things like the context menu, that might want subsequent tabs to open in the same CWD, but poorly for wt -w 0 --cwd C:\foo nt

[zadjii-msft]

From @UmbralReaper in #12200

I like to start windows terminal through the search function in the taskbar, or through PowerToys Run. However, both of these end up in undesirable starting locations when windows terminal inherits the parent process (C:\Windows\System32 and ~\AppData\Local\Microsoft\WindowsApps, respectively). However, setting a more desirable default start location (such as %USERPROFILE) prevents inheriting the location when it is useful.

I propose that you allow setting aliases for start locations in settings.

{
    "start_aliases": {
        "C:\\Windows\\System32": "%USERPROFILE%",
        "%USERPROFILE%\\AppData\\Local\\Microsoft\\WindowsApps": "%USERPROFILE%"
    }
}

[zadjii-msft]

Some notes: a work in progress 🏗️

Scenarios

• A: "Use parent process directory" still works after the 1.18 process model changes (untracked)
• B: "The terminal doesn't lock the directory it was started in" (Terminal locks its starting directory; perhaps it shouldn't do that? #5506)
• C: Ctrl+clicking on a "Use parent process directory" profile starts it in the original terminal's CWD. (After updating Windows Terminal, pressing Ctrl+Profile will not inherit the working directory #15173)
• D: The user can set the CWD of the Terminal itself (Other options for overriding profile starting directory #4637)
• E: The user can change the CWD of the terminal itself (Other options for overriding profile starting directory #4637)
• F: An auto-elevate default profile, with a "Use parent process directory" profile, should inherit the CWD that the terminal was ORIGINALLY started with (before it was auto-elevated) ('Use parent process directory' not being respected for new Tabs #14817)
• G: I want to use the CWD of the current tab/pane in a newTab/splitPane: ALREADY POSSIBLE, see Opening a tab or pane in the same directory in Windows Terminal

Scenario A & B

"Use parent process directory" still works after the 1.18 process model changes
"The terminal doesn't lock the directory it was started in"

• I'm gonna give each window a "virtual working directory".
• startingDirectorys will be evaluated relative to that
• running wt -w new in c:\some\path will set that window's virtual CWD to c:\some\path
• The terminal will always use c:\windows\system32 as it's actual CWD
• "Use parent process directory" I suppose now just means "use the window's CWD"

This is in 816f8b2

Warning Breaking change‼️

This will break a profile like

            {
                "commandline": "media-test.exe",
                "hidden": false,
                "name": "Use CWD for media-test",
                "startingDirectory": "."
            },

if the user right-clicks "open in terminal", then attempts to open that profile. UNLESS we do some work down in D/E

Scenario C

Ctrl+clicking on a "Use parent process directory" profile starts it in the original terminal's CWD.

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.

A 1.18 version of this, which builds on A&B, is in 3d1611f

Scenario D & E

The user can set & change the CWD of the terminal itself

A couple new features:

• wt --initialCwd c:\foo: New wt-level parameter. When starting terminal, set the CWD to c:\foo. Does nothing if running this in an existing window.
• wt change-directory c:\bar: A new wt subcommand. Change the Terminal's virtual CWD to c:\bar. This would work for other windows, the current window
• displayTerminalCwd: new action. pop a toast to display the Terminal's own CWD
• changeTerminalCwd: new action.
  • With a path: Set the terminal's virtual CWD to that path.
  • Without a path: Open a window-renamer-esque toast for repathing the terminal itself.

displayTerminalCwd toast is in 0726206

Potential fix for the C break

We change the shell extension to call wt --initialCwd <path> instead of wt -d <path>. This will make the shell extension open the new Terminal window in the provided CWD, rather than just the tab.

Scenario F

An auto-elevate default profile, with a "Use parent process directory" profile, should inherit the CWD that the terminal was ORIGINALLY started with (before it was auto-elevated)

• We launch elevate-shim --initialCwd <terminal's CWD> new-tab -p {guid} -d <path>.
  • This will set the elevated Terminal's cwd to whatever the CWD of the spawning terminal.
  • Subsequent "use parent process" profiles will work as expected in that window
  • If you've got the Terminal set to "attach to the most recently used window", then this won't change the CWD of an existing elevated Terminal window, but it will open the new tab in that directory

Planning

• A is a severe regression in 1.18
• C is a major regression in 1.16
• F might be a regression in 1.16 (unconfirmed if it ever worked)

A & B can be done for 1.18, with mild risk.
C can be done on top of A&B, for 1.18, with mild risk. Unclear if a similar fix would work for a 1.17 servicing release.
D,E,F all seem too risky for 1.18 at this point, but could be early 1.19 features.

References

Lemme just cross link a bunch of threads. I used to have a better mental map for this problem space. I thought there was one for "Set Terminal's CWD" but I can't find that now.

• Terminal locks its starting directory; perhaps it shouldn't do that? #5506
  • ye olde "Terminal's actual CWD should be system32 always and it should maintain a virtual CWD"
• 'Use parent process directory' not being respected for new Tabs #14817
  • not super relevant, really only for admin/elevated
• Proposal: Evolution of startingDirectory #9991
  • which points at...
• Other options for overriding profile starting directory #4637
  • This was the thread I was looking for!
• [Setting] New tab button should open another of the currently selected tab #445
  • Has other relevant thoughts on the matter

[oldium]

I would call the current situation the “default directory madness”:

1. I have the PowerShell default profile set to start in %USERPROFILE% to prevent opening in otherwise useless system32 (this applies to all my WSL2 profiles too, which are set to start in WSL2 home directory ~). This default is used when I click on the pinned Terminal icon on the taskbar.
2. Because the default profile opens in the fixed place, I cannot use wt command to open terminal in the parent process directory. Thus, I have a batch file wtd.cmd with wt -d . %* in it, which opens the Terminal in the current directory. I use this to open the terminal from Double Commander for example.
3. When I want to open another terminal in the same directory, I need to use a non-default profile, which has the “Use parent process directory” enabled (this applies to all my WSL2 profiles too).

So in summary: I doubled every profile and I also created a script to actually open the terminal.

The following behaviour would cover my use case:

1. Pinned Terminal app opens in user's home directory, which is either %USERPROFILE% for Windows apps (PowerShell/cmd.exe/Developer Command Prompt...), or ~ (for WSL2).
2. Every new Terminal window opens in the parent process directory.
3. Terminal started from an app (like Double Commander) opens in the parent process directory.

[ColinPMTCG]

Interesting issue with the start in parent process directory option - if you subsequently delete that directory, you cannot start another tab without an error (this example is with Command Prompt as the default):

[error 2147942667 (0x8007010b) when launching `%SystemRoot%\System32\cmd.exe']
Could not access starting directory "C:\MyRecentlyDeletedDirectory"

On Windows 11 23H2 (OS Build 22631.3880) with Windows Terminal 1.20.11781.0