-
Notifications
You must be signed in to change notification settings - Fork 8.5k
New issue
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
Comments
Oh, boy. You're totally right, this is a regression. It also breaks Scott Hanselman's "Open WT here" shortcut.
So there's a problem. Maybe the right decision is to return 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. |
Ah. Without checking how it actually worked, I kind of assumed it was detectable if the
I like the current default of |
I think we can let -p "P:\ath\to\some\directory" and use that path for the starting directory, otherwise respecting the profile settings. This way you can type I don't think having 2 different behaviors depending on whether the parent process is
(Plus, I guess since Start now has its own process |
Great solution! Maybe the the
Totally agreed. The solution you mentioned ( |
We’ll have to converge with the people who want |
@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). |
@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 I think it'd be nice if WT could also implement this widely used pattern. Using a Sorry for not coming up with a better solution. Just wanted to reiterate the point. |
My profile has Know that I am using the current store version: 0.2.1715.0 |
@ffes You will get |
@fghzxm You're right. The default profile you get when you install it for the first time should have the |
I'm totally agree with @nphmuller from this comment. In my workflow there is no time to remember about -p parameter. For me behavior same like cmd, powershell, sh ... is killer feature of Windows explorer. It would be nice when |
+1 |
That's not exactly true. The problem here is that |
@DHowett-MSFT is correct. "startingDirectory": "\\\\wsl$\\Ubuntu\\home\\joe" |
This workaround no longer seems to be functioning with the latest update. The issue however still remains. (When I say latest update, I am referring to the build available via the MSFT store.) |
@ipat8 I just installed it this seems to be working for me (installed today from https://www.microsoft.com/store/productId/9N0DX20HK701) |
What I am used to be doing is going through directories in total commander, when in right spot typing "cmd" or "Powershell" to open a cmd line to run some commands. The same way I used to switch between cmd, Powershell or bash. I know these are shells, and this is terminal - however, in the end, all these are "windows where you can type in commands" :). For the benefit of people looking like me for how this can be worked around for now: |
Run: wt.reg
|
@akunzai 's solution works for me! Thanks. |
I don't see it explicitly mentioned in this thread, but adding/setting hopefully this makes it clearer for people arriving here by Google or whatever. |
Hi, But when I run Below my settings. How to start windows terminal from current explorer folder, running simply wt? Thank you "profiles":
{
"defaults":
{
"startingDirectory": "."
},
"list":
[
{
"commandline": "powershell.exe",
"guid": "{61c54bbd-c2c6-5271-96e7-009a87ff44bf}",
"hidden": false,
"name": "Windows PowerShell"
},
{
"commandline": "cmd.exe",
"guid": "{0caa0dad-35be-5f56-a8ff-afceeeaa6101}",
"hidden": false,
"name": "Prompt dei comandi"
},
{
"commandline": "wsl -d WLinux cd ~; $SHELL --login",
"guid": "{7f586916-8357-53d4-bb2b-ca96f639898a}",
"hidden": false,
"name": "WLinux",
"source": "Windows.Terminal.Wsl",
"startingDirectory": "."
},
{
"guid": "{b453ae62-4e3d-5e58-b989-0a998ec441b8}",
"hidden": false,
"name": "Azure Cloud Shell",
"source": "Windows.Terminal.Azure"
},
{
"commandline": "nu.exe",
"guid": "{2b372ca1-1ee2-403d-a839-6d63077ad871}",
"hidden": false,
"name": "Nu Shell"
}
]
} |
This is because you have configured your commandline to include |
I'm stupid. Solved, thank you |
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. |
I'm here from this issue #11544 I think it's important to make this command tool compatible with the entire command line ecosystem. |
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 inc:\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 launchingwt.exe
(orwtd.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
startingDirectory
is set to%USERPROFILE%
:wt
(orwtd
) in the address bardExpected 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.
The text was updated successfully, but these errors were encountered: