Skip to content
{{ message }}

## microsoft / terminal Public

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

# Starting directory no longer respected#878

Closed
opened this issue May 17, 2019 · 56 comments
Closed

# Starting directory no longer respected#878

opened this issue May 17, 2019 · 56 comments
Labels
Area-Settings Issue-Bug Product-Terminal Resolution-Won't-Fix
Milestone

## Comments

### nphmuller commented May 17, 2019 • edited

Commit where this occurs: e0f131121b08dc5d6485e4bd985ac2c7e32b6339
Commit where this didn't occur yet: d5b8e7c32f7a419a7d467eab038251ee529056e6

Since the startingDirectory profiles.json setting was introduced (which is set to %USERPROFILE% by default), the current starting directory is no longer respected and the terminal always starts in %USERPROFILE%.

The startingDirectory setting is great to make sure the terminal doesn't always start in c:\windows\system32. It might however be better that its not used when starting Windows Terminal from a folder.

With starting WT from a folder I mean launching wt.exe (or wtd.exe) from an open cmd, or in Windows Explorer via its address bar.

The folder of the parent cmd process (or Explorer process) should then be used by default and startingDirectory should be used as a fallback. For example, when launching Windows Terminal from the start menu.

# Steps to reproduce

• Make sure startingDirectory is set to %USERPROFILE%:
{
...
"profiles": [{
"startingDirectory": "%USERPROFILE%",
}, {
...
}
],
...
}
• Open an explorer window in a random folder (for example the root of the C drive)
• Type wt (or wtd) in the address bard

# Expected behavior

Windows Terminal should open with the terminals path set to the folder opened in explorer. In the example this would be the root of the C drive: C:\.

# Actual behavior

Windows Terminal opens with the terminals path set to the user profile path.

bot added the Needs-Triage label May 17, 2019

### DHowett-MSFT commented May 17, 2019 • edited

 Oh, boy. You're totally right, this is a regression. It also breaks Scott Hanselman's "Open WT here" shortcut. not used when starting Windows Terminal from a folder So there's a problem. C:\Windows\System32 is a folder. I'd rather not detect "folders we care about" versus "folders we don't care about," as those two lists can get pretty long. Maybe the right decision is to return {profile}.startingDirectory to being fully optional and revert parts of #604? @fghzxm will probably have an opinion here. There's a split in user desire here: some people want the profile to indicate a starting directory, and some want WT to launch whatever profile you specify on the command line (#607) in the directory in which they start it. Hmm.

added Area-Settings Issue-Bug Product-Terminal and removed Needs-Triage labels May 17, 2019

### nphmuller commented May 17, 2019

 So there's a problem. C:\Windows\System32 is a folder. Ah. Without checking how it actually worked, I kind of assumed it was detectable if the cmd (or other) process was launched directly vs if it was launched in a folder. But I guess since cmd.exe is in PATH its basically the same for the process and only the cwd differs. Maybe the right decision is to return {profile}.startingDirectory to being fully optional and revert parts of #604? I like the current default of startingDirectory being the home directory. But if I had to choose between either home directory vs cwd, I'd choose cwd. Of course its just my opinion though...

### fghzxm commented May 17, 2019 • edited

 I think we can let wt.exe have a command line option -p "P:\ath\to\some\directory" and use that path for the starting directory, otherwise respecting the profile settings. This way you can type wt.exe -p . and get the behavior you want. We probably should also have a look at how terminal emulators on other platforms behave in this aspect, but I think gnome-terminal always launches the shell in my home directory... I don't think having 2 different behaviors depending on whether the parent process is cmd.exe, explorer.exe or some other is a good thing because The differing behaviors are confusing to the user, and The user could still launch wt.exe from msys2 bash, cygwin bash or any other alternative shell of which we would have to maintain a list that can never be exhaustive. (Plus, I guess since Start now has its own process StartMenuExperienceHost.exe, the actual parent of the processes launched from Start will be that process instead?)

### nphmuller commented May 17, 2019

 This way you can type wt.exe -p . and get the behavior you want. Great solution! Maybe the the -p parameter can also be used as the default (unnamed) parameter. That way we can even use wt.exe .. Which looks like the workflow many apps use (explorer ., code .) I don't think having 2 different behaviors depending on whether the parent process is cmd.exe, explorer.exe or some other is a good thing because Totally agreed. The solution you mentioned (-p) is simple and predictable.

### DHowett-MSFT commented May 17, 2019

 We’ll have to converge with the people who want wt.exe cmd and wt.exe ssh example@example.com, plus the people who want wt.exe {profileguid}. Let’s talk about that in #607.

### fghzxm commented May 17, 2019

 @nphmuller I would rather like to reserve the unnamed parameter for the profile name, which I think is more useful (of course this is up to personal tastes).

mentioned this issue May 30, 2019

### nphmuller commented Jun 7, 2019

 @fghzxm For my personally they both are about just as important. So that doesn't help. 😁 My main point is: Bash (WSL), cmd, PowerShell, Windows Explorer and VSCode (Explorer and VSCode via the . parameter) implemented a pattern where I could simply type the name of the executable, and it would open in the current directory. When starting via the start menu (or Run) it starts in the home directory, (or in a default view in the case on Explorer and VSCode). I think it'd be nice if WT could also implement this widely used pattern. Using a -p parameter would work, but it would make this a bit harder the guess, and harder to use because it requires WT specific know-how. Sorry for not coming up with a better solution. Just wanted to reiterate the point.

added this to the Terminal Backlog milestone Jun 19, 2019

### DHowett commented Aug 15, 2021

 This is because you have configured your commandline to include cd ~, which totally overrides your starting directory by moving to your Linux home directory no matter what you do.

### aborruso commented Aug 15, 2021

 This is because you have configured your commandline to include cd ~, which totally overrides your starting directory by moving to your Linux home directory no matter what you do. I'm stupid. Solved, thank you

mentioned this issue Oct 20, 2021
mentioned this issue Nov 22, 2021
mentioned this issue Nov 29, 2021

### Zingam commented Nov 29, 2021

 This must be an annoying issue, seeing how many people fail to find it and get's repeated over and over. :) Maybe Windows could provide an API to solve this issue and it may be even useful to many other applications.

mentioned this issue Mar 17, 2022
to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Area-Settings Issue-Bug Product-Terminal Resolution-Won't-Fix
Projects
None yet
Development

No branches or pull requests