startingDirectory and splitMode ignored in settings file

[amine-aboufirass]

Windows Terminal version

1.14.1962.0

Windows build number

10.0.19042.0

Other Software

No response

Steps to reproduce

{
    "$help": "https://aka.ms/terminal-documentation",
    "$schema": "https://aka.ms/terminal-profiles-schema",
    "actions": 
    [
        {
            "command": 
            {
                "action": "copy",
                "singleLine": false
            },
            "keys": "ctrl+c"
        },
        {
            "command": "paste",
            "keys": "ctrl+v"
        },
        {
            "command": "find",
            "keys": "ctrl+shift+f"
        },
        {
            "command": 
            {
                "action": "splitPane",
                "split": "down",
                "splitMode": "duplicate"
            },
            "keys": "alt+shift+minus"
        }
    ],
    "copyFormatting": "none",
    "copyOnSelect": false,
    "defaultProfile": "{dd06fdc4-e3c7-404a-ba9c-ead0245d608b}",
    "profiles": 
    {
        "defaults": {
			
		},
        "list": 
        [
            {
                "commandline": "%SystemRoot%\\System32\\WindowsPowerShell\\v1.0\\powershell.exe",
                "guid": "{61c54bbd-c2c6-5271-96e7-009a87ff44bf}",
                "hidden": false,
                "name": "Windows PowerShell"
            },
            {
                "commandline": "%SystemRoot%\\System32\\cmd.exe",
                "guid": "{0caa0dad-35be-5f56-a8ff-afceeeaa6101}",
                "hidden": false,
                "name": "Command Prompt"
            },
            {
                "guid": "{574e775e-4f2a-5b96-ac1e-a2962a402336}",
                "hidden": false,
                "name": "PowerShell",
                "source": "Windows.Terminal.PowershellCore"
            },
            {
                "guid": "{b453ae62-4e3d-5e58-b989-0a998ec441b8}",
                "hidden": false,
                "name": "Azure Cloud Shell",
                "source": "Windows.Terminal.Azure"
            },
            {
                "commandline": "pwsh.exe -ExecutionPolicy ByPass -NoExit -Command \"& C:\\Users\\amine.aboufirass\\miniconda3\\shell\\condabin\\conda-hook.ps1 ; conda activate C:\\Users\\amine.aboufirass\\miniconda3\"",
                "guid": "{db6044f2-9daa-458b-afd6-20cbd1db506d}",
                "hidden": false,
                "name": "Anaconda Powershell Prompt"
            },
            {
                "commandline": "\"C:\\Program Files\\PowerShell\\7\\pwsh.exe\" -noe -c \"&{Import-Module \"\"\"C:\\Program Files (x86)\\Microsoft Visual Studio\\2019\\Professional\\Common7\\Tools\\Microsoft.VisualStudio.DevShell.dll\"\"\"; Enter-VsDevShell f47eb35f}\"",
                "guid": "{dd06fdc4-e3c7-404a-ba9c-ead0245d608b}",
                "hidden": false,
                "name": "Developer Command Prompt VS2019",
				"startDirectory": "D:/Dev"
            }
        ]
    },
    "schemes":  [...]
}

• The opened default prompt (Developer Command Prompt VS2019) Does not open in the directory listed under startDirectory
• When attempting to split a pane horizontally using shift+alt+- the new pane does not replicate the same directory, unless it is the home directory

Expected Behavior

I expect splitMode="duplicate to start any new panes in the directory of the parent pane.
I expect startingDirectory="D:/Dev" to open the profile in D:/Dev

Actual Behavior

splitMode="duplicate to starts any new panes in home directory regardless of which directory the parent pane is in
startingDirectory="D:/Dev" does not affect the default directory when opening the terminal

[237dmitry]

startingDirectory or startDirectory in YOUR settings.json?

[amine-aboufirass]

@237dmitry I tried both. Neither worked.

[zadjii-msft]

Firstly, yea it's startingDirectory.

Second, did you configure your shell to actually tell the Terminal about it's CWD/?

[amine-aboufirass]

@zadjii-msft I added the following to my Powershell profile based on the link you provided:

function prompt {
  $loc = $($executionContext.SessionState.Path.CurrentLocation);
  $out = "PS $loc$('>' * ($nestedPromptLevel + 1)) ";
  $out += "$([char]27)]9;9;`"$loc`"$([char]27)\"
  return $out
}

Then I double checked that my settings included startingDirectory, which they were.

The behavior unfortunately persists. I still have the same problem.

[zadjii-msft]

Hmm. Maybe the cwd sequence is getting lost.

Can you try opening this profile with the debug tap to get a trace of all the input and output/? Once it's open, cd once, just to make sure that CWD changes propagate out. Send us a screenshot and we might be able to figure out what the Terminal thinks it's getting here.

---

Alternatively, maybe it's the `"alt+shift+minus"` that's tripping up the keybindings. Those ones are sometimes a little wonky, esp on other keyboard layouts. As a sanity check, try binding that to something like, `f1` instead.

[amine-aboufirass]

Here's the output from the debug tap:

Using "f1" instead of "alt+shift+minus" in the keybinding does not make a difference.

[amine-aboufirass]

I changed the relevant part in settings.json to

{
            "command": 
            {
                "action": "splitPane",
                "split": "horizontal",
                "splitMode": "duplicate"
            },
            "keys": "shift+alt+-"
        }
}

And now it seems to duplicate the profile and CWD in all profiles except for the Visual Studio Developer command prompt. That seems to indicate that Windows Terminal works fine, and there's something about the way I've set up the Visual Studio profile which causes it to behave this way. Closing.

[zadjii-msft]

Huh. Interesting! I know there have been issues with that in the past with ubuntu.exe as well. Maybe Enter-VsDevShell always switches the CWD to %USERPROFILE%\source\repos, regardless of the starting directory.

Glad you (sorta) figured it out!

[amine-aboufirass]

Sorry, I have to reopen this. I tried using the same settings file on another machine and got the same unwanted behavior. So I'm leaning more towards the idea that this is definitely Windows Terminal related.

[zadjii-msft]

got the same unwanted behavior

Like, got the same behavior with cmd/powershell? I thought we had debugged this down to an issue with Enter-VsDevShell/?

[amine-aboufirass]

@zadjii-msft We hadn't debugged anything, really. I submitted the debug tap like you asked and then closed the issue before you had a chance to respond when I (incorrectly) concluded my issue was resolved.

I'm not sure what Enter-VsDevShell is, but I don't think we had gotten far enough to determine the root cause of this issue. I would kindly refer you back to the debug tap I submitted a couple of days ago.

[DHowett]

I'm sorry for the radio silence here! Thanks for your patience.

Based on the symptoms and your configuration here, it seems like there are two issues:

1. If you have not configured cmd/powershell to "tell" terminal about their starting directory, duplicate doesn't work properly. This is an unfortunate but documented consequence of how processes on Windows work.
2. the VS dev shells are impacted explicitly, even if you follow the above docs

For 1, the docs reign supreme. For 2, however... every VS dev shell profile is configured to use a Visual Studio command Enter-VsDevShell. That command(let) explicitly overrides any starting directory, which is somewhat frustrating. You can fix this by adding -SkipAutomaticLocation to the commandline for any VS Dev Shell profile. We should document or fix this.

Does that help at all?

[amine-aboufirass]

@DHowett I see, so this appears to be specific for profiles that use VsDevShell. Yes, in my case adding -SkipAutomaticLocation does help. When I split the pane it now keeps the same base folder as the one specified in my original pane. Thanks.

[DHowett]

Thanks for confirming!

Personally, I'd love to add that for everyone . . . @heaths, how integral to the continuity of "dev shell" is that it ignore the user's starting directory? I know that the start menu shortcuts work one way, but perhaps we can change that contract a bit?

[heaths]

I doubt it's needed. I imagine it was probably maintained for legacy reasons, but since env vars like PATH are updated I see little reason to maintain it i.e., just blindly add -SkipAutomaticLocation to each profile going forward. Let me track down an owner for the scripts and see if they'll comment otherwise.

[carlos-zamora]

@heaths did you have any luck?

[heaths]

@trippwill indicated in email with @DHowett and I that it should be safe to add. It's been available since the PowerShell dev prompt was added, which I seem to recall this code assumes already.

[DHowett]

Oh, I just realized that you're not even using the automatically generated VS profiles! Hah!

It also turns out that our automatically-generated VS PowerShell profiles already use -SkipAutomaticLocation.

I'm gonna close this out, but I have made sure that the CMD version of these profiles does the same thing in #15035.