Starting directory no longer respected #1190

@fghzxm commented on GitHub (May 17, 2019):

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?)

@fghzxm commented on GitHub (May 17, 2019): I think we can let `wt.exe` have a command line option ```cmd -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?)

claunia commented

@nphmuller commented on GitHub (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.

@nphmuller commented on GitHub (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.

claunia commented

@DHowett-MSFT commented on GitHub (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.

@DHowett-MSFT commented on GitHub (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.

claunia commented

@fghzxm commented on GitHub (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).

@fghzxm commented on GitHub (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).

claunia commented

@nphmuller commented on GitHub (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.

@nphmuller commented on GitHub (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.

claunia commented

@ffes commented on GitHub (Jun 24, 2019):

My profile has "commandline": "wsl.exe -d Ubuntu". I expect it to start in $HOME aka ~ and not in /mnt/c/Windows/SYSTEM32.

Know that startingDirectory is not set for this profile. That is how the profile was created when installed on my machine.

I am using the current store version: 0.2.1715.0

@ffes commented on GitHub (Jun 24, 2019): My profile has `"commandline": "wsl.exe -d Ubuntu"`. I expect it to start in `$HOME` aka `~` and not in `/mnt/c/Windows/SYSTEM32`. Know that `startingDirectory` is not set for this profile. That is how the profile was created when installed on my machine. I am using the current store version: 0.2.1715.0

claunia commented

@fghzxm commented on GitHub (Jun 24, 2019):

@ffes You will get /mnt/c/Windows/System32 if you invoke the plain wsl command. You want wsl ~.

@fghzxm commented on GitHub (Jun 24, 2019): @ffes You will get `/mnt/c/Windows/System32` if you invoke the plain `wsl` command. You want `wsl ~`.

claunia commented

@ffes commented on GitHub (Jun 24, 2019):

@fghzxm You're right.

The default profile you get when you install it for the first time should have the ~ added, but that is most likely another issue.

@ffes commented on GitHub (Jun 24, 2019): @fghzxm You're right. The default profile you get when you install it for the first time should have the `~` added, but that is most likely another issue.

claunia commented

@bmlynarczyk commented on GitHub (Jun 25, 2019):

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 wt will be compatible with shuch a behavior.

@bmlynarczyk commented on GitHub (Jun 25, 2019): I'm totally agree with @nphmuller from this [comment](https://github.com/microsoft/terminal/issues/878#issuecomment-499825939). 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 `wt` will be compatible with shuch a behavior.

claunia commented

@twopoint71 commented on GitHub (Aug 8, 2019):

+1
In version: 0.3.2171.0 startingDirectory is not respected. Strictly defaults to %USERPROFILE% where I want "~" for default wsl.exe shells.

@twopoint71 commented on GitHub (Aug 8, 2019): +1 In version: 0.3.2171.0 startingDirectory is not respected. Strictly defaults to %USERPROFILE% where I want "~" for default wsl.exe shells.

claunia commented

@DHowett-MSFT commented on GitHub (Aug 8, 2019):

That's not exactly true. The problem here is that startingDirectory is a windows path.

@DHowett-MSFT commented on GitHub (Aug 8, 2019): That's not exactly true. The problem here is that `startingDirectory` is a _windows path_.

claunia commented

2026-01-30 22:18:39 +00:00

@joemaller commented on GitHub (Aug 14, 2019):

@DHowett-MSFT is correct. "startingDirectory": "~" doesn't work for WSL shells, but this does:

  "startingDirectory": "\\\\wsl$\\Ubuntu\\home\\joe"

@joemaller commented on GitHub (Aug 14, 2019): @DHowett-MSFT is correct. `"startingDirectory": "~"` doesn't work for WSL shells, but this does: ```json "startingDirectory": "\\\\wsl$\\Ubuntu\\home\\joe" ```

claunia commented

@ipat8 commented on GitHub (Aug 29, 2019):

@DHowett-MSFT is correct. "startingDirectory": "~" doesn't work for WSL shells, but this does:
  "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 commented on GitHub (Aug 29, 2019): > @DHowett-MSFT is correct. `"startingDirectory": "~"` doesn't work for WSL shells, but this does: > > ```json > "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.)

claunia commented

2026-01-30 22:18:39 +00:00

@nsheaps commented on GitHub (Sep 1, 2019):

@ipat8 I just installed it this seems to be working for me (installed today from https://www.microsoft.com/store/productId/9N0DX20HK701)

@nsheaps commented on GitHub (Sep 1, 2019): @ipat8 I just installed it this seems to be working for me (installed today from https://www.microsoft.com/store/productId/9N0DX20HK701)

claunia commented

2026-01-30 22:18:39 +00:00

@Kaszaq commented on GitHub (Sep 2, 2019):

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" :).
Need to type anything extra would make terminal work differently to how it currently works in cmd, bash or Powershell.

For the benefit of people looking like me for how this can be worked around for now:
You need to remove "startingDirectory" : "%USERPROFILE%", from profiles.json and then wt will start in the directory you are in. [I have version 0.4.2382.0]

@Kaszaq commented on GitHub (Sep 2, 2019): 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" :). Need to type anything extra would make terminal work differently to how it currently works in cmd, bash or Powershell. For the benefit of people looking like me for how this can be worked around for now: You need to remove `"startingDirectory" : "%USERPROFILE%",` from `profiles.json` and then `wt` will start in the directory you are in. [I have version 0.4.2382.0]

claunia commented

@ipat8 commented on GitHub (Sep 3, 2019):

@ipat8 I just installed it this seems to be working for me (installed today from https://www.microsoft.com/store/productId/9N0DX20HK701)

Not sure what issue I'm experiencing then, as I've copy pasted it into my config except for changing my username.

"startingDirectory" : "\\\\wsl$\\Ubuntu\\home\\moose",

Edit: Here is the entire config:

{
"acrylicOpacity" : 0.5,
"closeOnExit" : true,
"colorScheme" : "Campbell",
"commandline" : "wsl.exe -d Ubuntu-18.04",
"cursorColor" : "#FFFFFF",
"cursorShape" : "bar",
"fontFace" : "Consolas",
"fontSize" : 10,
"guid" : "{c6eaf9f4-32a7-5fdc-b5cf-066e8a4b1e40}",
"historySize" : 9001,
"icon" : "ms-appx:///ProfileIcons/{9acb9455-ca41-5af7-950f-6bca1bc9722f}.png",
"name" : "Ubuntu-18.04",
"padding" : "0, 0, 0, 0",
"snapOnInput" : true,
"startingDirectory" : "\\wsl$\Ubuntu\home\moose",
"useAcrylic" : false
},

@ipat8 commented on GitHub (Sep 3, 2019): > @ipat8 I just installed it this seems to be working for me (installed today from https://www.microsoft.com/store/productId/9N0DX20HK701) Not sure what issue I'm experiencing then, as I've copy pasted it into my config except for changing my username. `"startingDirectory" : "\\\\wsl$\\Ubuntu\\home\\moose",` Edit: Here is the entire config: > { "acrylicOpacity" : 0.5, "closeOnExit" : true, "colorScheme" : "Campbell", "commandline" : "wsl.exe -d Ubuntu-18.04", "cursorColor" : "#FFFFFF", "cursorShape" : "bar", "fontFace" : "Consolas", "fontSize" : 10, "guid" : "{c6eaf9f4-32a7-5fdc-b5cf-066e8a4b1e40}", "historySize" : 9001, "icon" : "ms-appx:///ProfileIcons/{9acb9455-ca41-5af7-950f-6bca1bc9722f}.png", "name" : "Ubuntu-18.04", "padding" : "0, 0, 0, 0", "snapOnInput" : true, "startingDirectory" : "\\\\wsl$\\Ubuntu\\home\\moose", "useAcrylic" : false },

claunia commented

@DHowett-MSFT commented on GitHub (Sep 3, 2019):

"commandline" : "wsl.exe -d Ubuntu-18.04",
"startingDirectory" : "\\wsl$\Ubuntu\home\moose",

You'll probably want \\\\wsl$\\Ubuntu-18.04\\home\\moose. The name after the wsl$ pseudotarget needs to match the distribution name.

@DHowett-MSFT commented on GitHub (Sep 3, 2019): > `"commandline" : "wsl.exe -d Ubuntu-18.04",` > `"startingDirectory" : "\\wsl$\Ubuntu\home\moose",` You'll probably want `\\\\wsl$\\Ubuntu-18.04\\home\\moose`. The name after the `wsl$` pseudotarget needs to match the distribution name.

claunia commented

@ipat8 commented on GitHub (Sep 3, 2019):

That did it, whoops.

@ipat8 commented on GitHub (Sep 3, 2019): That did it, whoops.

claunia commented

@akulbe commented on GitHub (Sep 3, 2019):

This answered a question for me too. 🙌🏻

@akulbe commented on GitHub (Sep 3, 2019): This answered a question for me too. 🙌🏻

claunia commented

@chiefjester commented on GitHub (Sep 16, 2019):

~~I'm just curious, why does the normal path need to be escaped? If the path is \\wsl$\Ubuntu\home\user why does it need to be \\\\wsl$\\Ubuntu\\home\\user?~~

Nevermind, it's a JSON thing.

@chiefjester commented on GitHub (Sep 16, 2019): ~~I'm just curious, why does the normal path need to be escaped? If the path is `\\wsl$\Ubuntu\home\user` why does it need to be `\\\\wsl$\\Ubuntu\\home\\user`?~~ Nevermind, it's a JSON thing.

claunia commented

@fghzxm commented on GitHub (Sep 17, 2019):

That’s not escaping. It’s part of the UNC pathhttps://docs.microsoft.com/en-us/dotnet/standard/io/file-path-formats#unc-paths.

Fred Miller

发件人: Chris notifications@github.com
发送时间: Tuesday, September 17, 2019 5:45:14 AM
收件人: microsoft/terminal terminal@noreply.github.com
抄送: fghzxm fghzxm@outlook.com; Mention mention@noreply.github.com
主题: Re: [microsoft/terminal] Starting directory no longer respected (#878)

I'm just curious, why does the normal path need to be escaped? If the path is "\wsl$\Ubuntu\home\user" why does it need to be ""\wsl$\Ubuntu\home\user"?

―
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://github.com/microsoft/terminal/issues/878?email_source=notifications&email_token=AH3NPERRKJYQ6G6YTAPIXMLQJ746VA5CNFSM4HNWA4M2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD62TRXI#issuecomment-531970269, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AH3NPEUNSECHLJDHRQPTH2DQJ746VANCNFSM4HNWA4MQ.

@fghzxm commented on GitHub (Sep 17, 2019): That’s not escaping. It’s part of the UNC path<https://docs.microsoft.com/en-us/dotnet/standard/io/file-path-formats#unc-paths>. Fred Miller ________________________________ 发件人: Chris <notifications@github.com> 发送时间: Tuesday, September 17, 2019 5:45:14 AM 收件人: microsoft/terminal <terminal@noreply.github.com> 抄送: fghzxm <fghzxm@outlook.com>; Mention <mention@noreply.github.com> 主题: Re: [microsoft/terminal] Starting directory no longer respected (#878) I'm just curious, why does the normal path need to be escaped? If the path is "\wsl$\Ubuntu\home\user" why does it need to be ""\\wsl$\Ubuntu\home\user"? ― You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub<https://github.com/microsoft/terminal/issues/878?email_source=notifications&email_token=AH3NPERRKJYQ6G6YTAPIXMLQJ746VA5CNFSM4HNWA4M2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD62TRXI#issuecomment-531970269>, or mute the thread<https://github.com/notifications/unsubscribe-auth/AH3NPEUNSECHLJDHRQPTH2DQJ746VANCNFSM4HNWA4MQ>.

claunia commented

@chiefjester commented on GitHub (Sep 18, 2019):

@fghzxm I think since you're reading the reply via email you're not seeing the 4 forward slash of before WSL and two forward slashes in the directory, check this screenshot, that's why I'm asking why it needed to be escaped and double the forward slashes.

If I try to just use one forward slash, I get an error in JSON saying it's a unicode character, even though it's between quotes.

@chiefjester commented on GitHub (Sep 18, 2019): @fghzxm I think since you're reading the reply via email you're not seeing the 4 forward slash of before WSL and two forward slashes in the directory, check this screenshot, that's why I'm asking why it needed to be escaped and double the forward slashes. ![image](https://user-images.githubusercontent.com/532797/65085932-c1081480-d964-11e9-9423-8354b981936a.png) If I try to just use one forward slash, I get an error in JSON saying it's a unicode character, even though it's between quotes. ![image](https://user-images.githubusercontent.com/532797/65085989-fe6ca200-d964-11e9-90eb-4d4b7423769a.png)

claunia commented

@chiefjester commented on GitHub (Sep 18, 2019):

I want to add my findings:

Sometimes, I revert to my windows home even though I've set it to "\\wsl$\Ubuntu\home\user".

@chiefjester commented on GitHub (Sep 18, 2019): I want to add my findings: Sometimes, I revert to my windows home even though I've set it to "\\\\wsl$\\Ubuntu\\home\\user". ![image](https://user-images.githubusercontent.com/532797/65086060-47245b00-d965-11e9-9ada-d40be19df62f.png)

claunia commented

2026-01-30 22:18:42 +00:00

@chiefjester commented on GitHub (Sep 18, 2019):

Just found this in the docs, seems like you can use forward slashes and not be bothered by escaping: //wsl$/Ubuntu/home/username.

@chiefjester commented on GitHub (Sep 18, 2019): Just found this in the [docs](https://github.com/microsoft/terminal/blob/master/doc/user-docs/UsingJsonSettings.md#profiles), seems like you can use forward slashes and not be bothered by escaping: `//wsl$/Ubuntu/home/username`.

claunia commented

@fghzxm commented on GitHub (Sep 19, 2019):

@Chris Yeah, I indeed did not see the doubled backward slashes in my email. I think then the need to double the slashes are because of JSON escaping, i. e. you have to type two slashes in order for they to translate to one in the represented string data, wherefore the unicode character error since the JSON parser was trying to interpret \Ubunt as an escape sequence which is not valid.

Fred Miller

From: Chris notifications@github.com
Sent: Wednesday, September 18, 2019 20:17
To: microsoft/terminal
Cc: fghzxm; Mention
Subject: Re: [microsoft/terminal] Starting directory no longer respected (#878)

Just found this in the docshttps://github.com/microsoft/terminal/blob/master/doc/user-docs/UsingJsonSettings.md#profiles, seems like you can use forward slashes and not be bothered by escaping://wsl$/Ubuntu/home/username.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://github.com/microsoft/terminal/issues/878?email_source=notifications&email_token=AH3NPERRPHXXGXHUW2EK4DDQKIL6FA5CNFSM4HNWA4M2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD673LNY#issuecomment-532657591, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AH3NPESTMJVFOXEM7YNPVCDQKIL6FANCNFSM4HNWA4MQ.

@fghzxm commented on GitHub (Sep 19, 2019): @Chris Yeah, I indeed did not see the doubled backward slashes in my email. I think then the need to double the slashes are because of JSON escaping, i. e. you have to type two slashes in order for they to translate to one in the represented string data, wherefore the unicode character error since the JSON parser was trying to interpret `\Ubunt` as an escape sequence which is not valid. Fred Miller ________________________________ From: Chris <notifications@github.com> Sent: Wednesday, September 18, 2019 20:17 To: microsoft/terminal Cc: fghzxm; Mention Subject: Re: [microsoft/terminal] Starting directory no longer respected (#878) Just found this in the docs<https://github.com/microsoft/terminal/blob/master/doc/user-docs/UsingJsonSettings.md#profiles>, seems like you can use forward slashes and not be bothered by escaping://wsl$/Ubuntu/home/username. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub<https://github.com/microsoft/terminal/issues/878?email_source=notifications&email_token=AH3NPERRPHXXGXHUW2EK4DDQKIL6FA5CNFSM4HNWA4M2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD673LNY#issuecomment-532657591>, or mute the thread<https://github.com/notifications/unsubscribe-auth/AH3NPESTMJVFOXEM7YNPVCDQKIL6FANCNFSM4HNWA4MQ>.

claunia commented

2026-01-30 22:18:42 +00:00

@daegalus commented on GitHub (Sep 22, 2019):

Just saw this issue, the following works fine for me for getting into the home directory for WSL:

"commandline": "wsl.exe ~ -d Ubuntu",

no startingDirectory entry for wsl

@daegalus commented on GitHub (Sep 22, 2019): Just saw this issue, the following works fine for me for getting into the home directory for WSL: `"commandline": "wsl.exe ~ -d Ubuntu",` no `startingDirectory` entry for wsl

claunia commented

2026-01-30 22:18:43 +00:00

@twopoint71 commented on GitHub (Sep 28, 2019):

A really simple work around is add cd to the end of bashrc.

echo "cd" >> ~/.bashrc

@twopoint71 commented on GitHub (Sep 28, 2019): A really simple work around is add `cd` to the end of bashrc. `echo "cd" >> ~/.bashrc`

claunia commented

2026-01-30 22:18:43 +00:00

@dlxeon commented on GitHub (Oct 1, 2019):

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" :).
Need to type anything extra would make terminal work differently to how it currently works in cmd, bash or Powershell.

For the benefit of people looking like me for how this can be worked around for now:
You need to remove "startingDirectory" : "%USERPROFILE%", from profiles.json and then wt will start in the directory you are in. [I have version 0.4.2382.0]

That was super useful, but now with latest Terminal 0.5.2681.0 that doesn't work. Are there any other ways to force start wt in current directory?

@dlxeon commented on GitHub (Oct 1, 2019): > > > 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" :). > Need to type anything extra would make terminal work differently to how it currently works in cmd, bash or Powershell. > > For the benefit of people looking like me for how this can be worked around for now: > You need to remove `"startingDirectory" : "%USERPROFILE%",` from `profiles.json` and then `wt` will start in the directory you are in. [I have version 0.4.2382.0] That was super useful, but now with latest Terminal 0.5.2681.0 that doesn't work. Are there any other ways to force start wt in current directory?

claunia commented

2026-01-30 22:18:43 +00:00

@zadjii-msft commented on GitHub (Oct 1, 2019):

As of v0.5, you'll need "startingDirectory": null for that workaround. This was regressed unintentionally, but it wasn't ever really a supported workaround, and we're still hoping for a real fix, but this will work for now.

@zadjii-msft commented on GitHub (Oct 1, 2019): As of v0.5, you'll need `"startingDirectory": null` for that workaround. This was regressed unintentionally, but it wasn't ever really a _supported_ workaround, and we're still hoping for a real fix, but this will work for now.

claunia commented

@zadjii-msft commented on GitHub (Oct 4, 2019):

Playing with this a bit today, inspired by @fcharlie's comment here.

I'm using a dev build to test this, but the same principles will apply for the Release/store installed packages as well.

I tested 6 scenarios. Obviously, for the start menu I couldn't set my own path before, but for the rest I used the C:\Users\migrie\dev dir. Additionally, I just typed wtd (the dev build alias) for each of the first 4 options:

Launch Origin	`GetCommandline()`	`GetCurrentDirectory()`
cmd.exe	`wtd`	"C:\Users\migrie\dev"
Windows Powershell	""C:\Users\migrie\AppData\Local\Microsoft\WindowsApps\wtd.exe"	"C:\Users\migrie\dev"
pwsh (6)	""C:\Users\migrie\AppData\Local\Microsoft\WindowsApps\wtd.exe"	"C:\Users\migrie\dev"
explorer	""C:\Users\migrie\AppData\Local\Microsoft\WindowsApps\wtd.exe"	"C:\Users\migrie\dev"
Click on entry in Start Menu	`""<path to package>\WindowsTerminal.exe" "`	"C:\WINDOWS\system32"
Search for "wtd" in Start Menu	`""<path to package>\WindowsTerminal.exe" "`	"C:\WINDOWS\system32"

Presumably, so long as the commandline doesn't match the path to the current executable, then we can infer that the user used the execution alias to start the Terminal, not the start menu.

That does seem a little fragile to me. Theoretically, someone could just use the whole path to the package to launch the Terminal from the commandline, and if we used the previous heuristic, it wouldn't work for that type of launch. Does that matter? Can we safely just say "inheriting the parents directory will only work for the wt alias?"

EDIT:

Launch Origin	`GetCommandline()`	`GetCurrentDirectory()`
`Win+R` wtd	""C:\Users\migrie\AppData\Local\Microsoft\WindowsApps\wtd.exe" "	"C:\Users\migrie"

This makes sense, and works with the previous heuristic

@zadjii-msft commented on GitHub (Oct 4, 2019): Playing with this a bit today, inspired by @fcharlie's comment [here](https://github.com/microsoft/terminal/issues/607#issuecomment-524501995). I'm using a dev build to test this, but the same principles will apply for the Release/store installed packages as well. I tested 6 scenarios. Obviously, for the start menu I couldn't set my own path before, but for the rest I used the `C:\Users\migrie\dev` dir. Additionally, I just typed `wtd` (the dev build alias) for each of the first 4 options: | Launch Origin | `GetCommandline()` | `GetCurrentDirectory()` | |--------------------------------|----------------------------------------------------------------|-------------------------| | cmd.exe | `wtd` | "C:\Users\migrie\dev" | | Windows Powershell | ""C:\Users\migrie\AppData\Local\Microsoft\WindowsApps\wtd.exe" | "C:\Users\migrie\dev" | | pwsh (6) | ""C:\Users\migrie\AppData\Local\Microsoft\WindowsApps\wtd.exe" | "C:\Users\migrie\dev" | | explorer | ""C:\Users\migrie\AppData\Local\Microsoft\WindowsApps\wtd.exe" | "C:\Users\migrie\dev" | | Click on entry in Start Menu | `""<path to package>\WindowsTerminal.exe" "` | "C:\WINDOWS\system32" | | Search for "wtd" in Start Menu | `""<path to package>\WindowsTerminal.exe" "` | "C:\WINDOWS\system32" | Presumably, so long as the commandline doesn't match the path to the current executable, then we can infer that the user used the execution alias to start the Terminal, _not_ the start menu. That does seem a little fragile to me. _Theoretically_, someone could just use the whole path to the package to launch the Terminal from the commandline, and if we used the previous heuristic, it wouldn't work for that type of launch. _Does that matter?_ Can we safely just say "inheriting the parents directory will only work for the `wt` alias?" <hr> EDIT: | Launch Origin | `GetCommandline()` | `GetCurrentDirectory()` | |--------------------------------|----------------------------------------------------------------|-------------------------| | <kbd>Win+R</kbd> wtd | ""C:\Users\migrie\AppData\Local\Microsoft\WindowsApps\wtd.exe" " | "C:\Users\migrie" | This makes sense, and works with the previous heuristic

claunia commented

@DHowett-MSFT commented on GitHub (Oct 4, 2019):

And from my investigation, you cannot launch a packaged application directly from its secret package path:

(dhowett-sb) ~ % & "$((Get-AppxPackage Microsoft.WindowsTerminal).InstallLocation)\WindowsTerminal.exe"
Program 'WindowsTerminal.exe' failed to run: Access is denied.

@DHowett-MSFT commented on GitHub (Oct 4, 2019): And from my investigation, you _cannot_ launch a packaged application directly from its secret package path: ``` (dhowett-sb) ~ % & "$((Get-AppxPackage Microsoft.WindowsTerminal).InstallLocation)\WindowsTerminal.exe" Program 'WindowsTerminal.exe' failed to run: Access is denied. ```

claunia commented

@zadjii-msft commented on GitHub (Oct 4, 2019):

Doing more digging, there's a winrt API that's probably exactly what we need. AppInstance::GetActivatedEventArgs(). I believe it's original purpose was to support multi-instance UWP applications, but it'll work for our purpose here.

For launches from the start menu, the IActivatedEventArgs.Kind() will return Launch.

For launches from shells, explorer.exe, AppInstance::GetActivatedEventArgs() will actually return nullptr.

So when it isn't null, and returns Launch, we should go ahead and tell the Terminal App to not use the startingDirectory for that launch.

I'll be out for the next couple weeks, so if someone passionate from the community wants to try and wet their toes in the codebase, this might be a good spot to try. (EDIT: check out dev/migrie/f/878-proto for a prototype)

Otherwise, expect a PR around Halloween 🎃

@zadjii-msft commented on GitHub (Oct 4, 2019): Doing more digging, there's a winrt API that's probably exactly what we need. `AppInstance::GetActivatedEventArgs()`. I believe it's original purpose was to support multi-instance UWP applications, but it'll work for our purpose here. For launches from the start menu, the `IActivatedEventArgs.Kind()` will return `Launch`. For launches from shells, explorer.exe, `AppInstance::GetActivatedEventArgs()` will actually return `nullptr`. So when it isn't null, and returns `Launch`, we should go ahead and tell the Terminal App to not use the `startingDirectory` for that launch. I'll be out for the next couple weeks, so if someone passionate from the community wants to try and wet their toes in the codebase, this might be a good spot to try. (EDIT: check out `dev/migrie/f/878-proto` for a prototype) * [GetCurrentDirectory](https://docs.microsoft.com/en-us/windows/win32/api/winbase/nf-winbase-getcurrentdirectory) * [A C# example of this API](https://docs.microsoft.com/en-us/windows/uwp/launch-resume/multi-instance-uwp) * [IActivatedEventArgs](https://docs.microsoft.com/en-us/uwp/api/windows.applicationmodel.activation.iactivatedeventargs) Otherwise, expect a PR around Halloween 🎃

claunia commented

@akunzai commented on GitHub (Oct 5, 2019):

Try "startingDirectory": "." for workaround.

see HERE for example.

@akunzai commented on GitHub (Oct 5, 2019): Try `"startingDirectory": "."` for workaround. see [HERE](https://gist.github.com/akunzai/b4b1f394db3ceb399ba1976a30e540fa) for example.

claunia commented

@piotrpalek commented on GitHub (Oct 10, 2019):

I have a different, but connected issue. Is it somehow possible to keep the current working directory when I open a tab or split from within Windows Terminal itself?

What I mean is:

I run Windows Terminal
I navigate to D:\
I open a new tab.
The tab is opened in the default location, instead of D:\

Same thing for splits.

@piotrpalek commented on GitHub (Oct 10, 2019): I have a different, but connected issue. Is it somehow possible to keep the current working directory when I open a tab or split from within Windows Terminal itself? What I mean is: 1. I run Windows Terminal 2. I navigate to `D:\` 3. I open a new tab. 4. The tab is opened in the default location, instead of `D:\` Same thing for splits.

claunia commented

@fle108 commented on GitHub (Oct 28, 2019):

Just found this in the docs, seems like you can use forward slashes and not be bothered by escaping: //wsl$/Ubuntu/home/username.

working for me today with Version: 0.6.2951.0

@fle108 commented on GitHub (Oct 28, 2019): > Just found this in the docs, seems like you can use forward slashes and not be bothered by escaping: //wsl$/Ubuntu/home/username. working for me today with Version: 0.6.2951.0

claunia commented

@Ujang360 commented on GitHub (Nov 8, 2019):

Just found this in the docs, seems like you can use forward slashes and not be bothered by escaping: //wsl$/Ubuntu/home/username.

//wsl$/Ubuntu-18.04/home/username for me, since I'm using Ubuntu 18.04 LTS from Microsoft Store.

@Ujang360 commented on GitHub (Nov 8, 2019): > Just found this in the [docs](https://github.com/microsoft/terminal/blob/master/doc/user-docs/UsingJsonSettings.md#profiles), seems like you can use forward slashes and not be bothered by escaping: `//wsl$/Ubuntu/home/username`. `//wsl$/Ubuntu-18.04/home/username` for me, since I'm using `Ubuntu 18.04 LTS` from Microsoft Store.

claunia commented

@iyh commented on GitHub (Jan 17, 2020):

Default startingDirectory for WSL should be ~ not %USERPROFILE%

@iyh commented on GitHub (Jan 17, 2020): Default `startingDirectory` for WSL should be `~` not `%USERPROFILE%`

claunia commented

@ligerzero459 commented on GitHub (Jan 21, 2020):

Just found this in the docs, seems like you can use forward slashes and not be bothered by escaping: //wsl$/Ubuntu/home/username.

This is still the workaround at the moment

@ligerzero459 commented on GitHub (Jan 21, 2020): > Just found this in the [docs](https://github.com/microsoft/terminal/blob/master/doc/user-docs/UsingJsonSettings.md#profiles), seems like you can use forward slashes and not be bothered by escaping: `//wsl$/Ubuntu/home/username`. This is still the workaround at the moment

claunia commented

@zadjii-msft commented on GitHub (Jan 28, 2020):

Hey all,

So this turned out to be a more complicated story that it seemed on the surface. There's more information in #3547 on all the edge cases with this scenario, feel free to read that thread if you're interested in more details.

Going forward, the official way to make this scenario work will be typing wt -d . into the explorer bar. That will tell wt to open in the current working directory. I know this isn't ideal, but frankly it's the only solution that still supports all the user stories we want. This functionality was added in #4023, and should be arriving in v0.9.

Thanks everyone!

@zadjii-msft commented on GitHub (Jan 28, 2020): Hey all, So this turned out to be a more complicated story that it seemed on the surface. There's more information in #3547 on all the edge cases with this scenario, feel free to read that thread if you're interested in more details. Going forward, the official way to make this scenario work will be typing `wt -d .` into the explorer bar. That will tell `wt` to open in the current working directory. I know this isn't _ideal_, but frankly it's the only solution that still supports all the user stories we want. This functionality was added in #4023, and should be arriving in v0.9. Thanks everyone!

claunia commented

@danielgjackson commented on GitHub (Jan 30, 2020):

(Apologies for adding a comment on a closed bug)

This seems like a difficult issue that has a lot to do with how the Start Menu entry is not a traditional "shortcut". Comparing with "Command Prompt" (PowerShell is similar), searching for "cmd.exe" or "Comm..." both find the same shortcut, and that has "%HOMEDRIVE%%HOMEPATH%" as the "Start in" folder. However, as "Windows Terminal" is not a traditional shortcut, you cannot specify a start folder, and the alias "wt"/"wtd" seems to be a completely separately generated entry(?)

However, I think a nice workaround would be nice to allow the profile to specify a different "startingDirectory" for each launch condition, e.g.

"startingDirectory" // When not ActivationKind.CommandLineLaunch
"startingDirectoryUI" // When ActivationKind.CommandLineLaunch

...then the defaults can be set to fix the main user stories, while remaining customizable for those who primarily launch from cmd or the Explorer address bar.

@danielgjackson commented on GitHub (Jan 30, 2020): (Apologies for adding a comment on a closed bug) This seems like a difficult issue that has a lot to do with how the Start Menu entry is not a traditional "shortcut". Comparing with "Command Prompt" (PowerShell is similar), searching for "cmd.exe" or "Comm..." both find the same shortcut, and that has "%HOMEDRIVE%%HOMEPATH%" as the "Start in" folder. However, as "Windows Terminal" is not a traditional shortcut, you cannot specify a start folder, and the alias "wt"/"wtd" seems to be a completely separately generated entry(?) However, I think a nice workaround would be nice to allow the profile to specify a different "startingDirectory" for each launch condition, e.g. "startingDirectory" // When not ActivationKind.CommandLineLaunch "startingDirectoryUI" // When ActivationKind.CommandLineLaunch ...then the defaults can be set to fix the main user stories, while remaining customizable for those who primarily launch from cmd or the Explorer address bar.

claunia commented

@Boobies commented on GitHub (Feb 27, 2020):

None of the things proposed here work any longer.

    "startingDirectory" : "\\\\wsl$\\Debian\\home\\<linuxuser>"

which is in the default Debian profile, actually leads me to a totally different predefined path: /mnt/c/Users/<WindowsUser>. I want my Linux home directory, not my Windows home directory.

PS: I tried the full Windows path to where the Debian home directory is stored, properly escaping it, and that lead me to Debian's root directory and no further than that.

@Boobies commented on GitHub (Feb 27, 2020): None of the things proposed here work any longer. "startingDirectory" : "\\\\wsl$\\Debian\\home\\<linuxuser>" which is in the default Debian profile, actually leads me to a totally different predefined path: `/mnt/c/Users/<WindowsUser>`. I want my Linux home directory, not my Windows home directory. PS: I tried the full Windows path to where the Debian home directory is stored, properly escaping it, and that lead me to Debian's root directory and no further than that.

claunia commented

@DHowett-MSFT commented on GitHub (Feb 27, 2020):

Can you share your profiles.json?

@DHowett-MSFT commented on GitHub (Feb 27, 2020): Can you share your profiles.json?

claunia commented

@Boobies commented on GitHub (Feb 27, 2020):

Sure:

// To view the default settings, hold "alt" while clicking on the "Settings" button.
// For documentation on these settings, see: https://aka.ms/terminal-documentation

{
    "$schema": "https://aka.ms/terminal-profiles-schema",

    "defaultProfile": "{58ad8b0c-3ef8-5f4d-bc6f-13e4c00f2530}",

    "alwaysShowTabs": true,
    "showTabsInTitlebar": false,

    "profiles":
    [
        {
            // Make changes here to the powershell.exe profile
            "guid": "{61c54bbd-c2c6-5271-96e7-009a87ff44bf}",
            "name": "Windows PowerShell",
            "commandline": "powershell.exe",
            "hidden": false
        },
        {
            // Make changes here to the cmd.exe profile
            "guid": "{0caa0dad-35be-5f56-a8ff-afceeeaa6101}",
            "name": "cmd",
            "commandline": "cmd.exe",
            "hidden": false
        },
        {
            "guid": "{58ad8b0c-3ef8-5f4d-bc6f-13e4c00f2530}",
            "hidden": false,
            "name": "Debian",
            "source": "Windows.Terminal.Wsl",

            "fontSize" : 9,
            "padding" : "0, 0, 0, 0",
            "startingDirectory" : "//wsl$/Debian/home/bogdan-barbu",
            "cursorShape" : "vintage"
        },
        {
            "guid": "{b453ae62-4e3d-5e58-b989-0a998ec441b8}",
            "hidden": false,
            "name": "Azure Cloud Shell",
            "source": "Windows.Terminal.Azure"
        }
    ],

    // Add custom color schemes to this array
    "schemes": [],

    // Add any keybinding overrides to this array.
    // To unbind a default keybinding, set the command to "unbound"
    "keybindings": []
}

@Boobies commented on GitHub (Feb 27, 2020): Sure: ``` // To view the default settings, hold "alt" while clicking on the "Settings" button. // For documentation on these settings, see: https://aka.ms/terminal-documentation { "$schema": "https://aka.ms/terminal-profiles-schema", "defaultProfile": "{58ad8b0c-3ef8-5f4d-bc6f-13e4c00f2530}", "alwaysShowTabs": true, "showTabsInTitlebar": false, "profiles": [ { // Make changes here to the powershell.exe profile "guid": "{61c54bbd-c2c6-5271-96e7-009a87ff44bf}", "name": "Windows PowerShell", "commandline": "powershell.exe", "hidden": false }, { // Make changes here to the cmd.exe profile "guid": "{0caa0dad-35be-5f56-a8ff-afceeeaa6101}", "name": "cmd", "commandline": "cmd.exe", "hidden": false }, { "guid": "{58ad8b0c-3ef8-5f4d-bc6f-13e4c00f2530}", "hidden": false, "name": "Debian", "source": "Windows.Terminal.Wsl", "fontSize" : 9, "padding" : "0, 0, 0, 0", "startingDirectory" : "//wsl$/Debian/home/bogdan-barbu", "cursorShape" : "vintage" }, { "guid": "{b453ae62-4e3d-5e58-b989-0a998ec441b8}", "hidden": false, "name": "Azure Cloud Shell", "source": "Windows.Terminal.Azure" } ], // Add custom color schemes to this array "schemes": [], // Add any keybinding overrides to this array. // To unbind a default keybinding, set the command to "unbound" "keybindings": [] } ```

claunia commented

@DHowett-MSFT commented on GitHub (Feb 27, 2020):

Excellent, and in powershell can you run gci \\wsl$\Debian\home

@DHowett-MSFT commented on GitHub (Feb 27, 2020): Excellent, and in powershell can you run `gci \\wsl$\Debian\home`

claunia commented

@Boobies commented on GitHub (Feb 27, 2020):

    Directory: \\wsl$\Debian\home


Mode                LastWriteTime         Length Name
----                -------------         ------ ----
d-----        2/27/2020   2:55 AM                bogdan_barbu

@Boobies commented on GitHub (Feb 27, 2020): ``` Directory: \\wsl$\Debian\home Mode LastWriteTime Length Name ---- ------------- ------ ---- d----- 2/27/2020 2:55 AM bogdan_barbu ```

claunia commented

@DHowett-MSFT commented on GitHub (Feb 27, 2020):

That looks like a _ instead of a -.

@DHowett-MSFT commented on GitHub (Feb 27, 2020): That looks like a `_` instead of a `-`.

claunia commented

@Boobies commented on GitHub (Feb 27, 2020):

Oh my. Sorry for wasting everyone's time. You can go ahead and delete this waste of space.

@Boobies commented on GitHub (Feb 27, 2020): Oh my. Sorry for wasting everyone's time. You can go ahead and delete this waste of space.

claunia commented

@luscas commented on GitHub (Sep 26, 2020):

Run: wt.reg

Windows Registry Editor Version 5.00

[HKEY_CLASSES_ROOT\Directory\Background\shell\wt\command]
@="%LOCALAPPDATA%\Microsoft\WindowsApps\wt.exe -d ."

@luscas commented on GitHub (Sep 26, 2020): Run: **wt.reg** ```regedit Windows Registry Editor Version 5.00 [HKEY_CLASSES_ROOT\Directory\Background\shell\wt\command] @="%LOCALAPPDATA%\Microsoft\WindowsApps\wt.exe -d ." ```

claunia commented

@happyTonakai commented on GitHub (Nov 27, 2020):

@akunzai 's solution works for me! Thanks.

@happyTonakai commented on GitHub (Nov 27, 2020): @akunzai 's solution works for me! Thanks.

claunia commented

@kenblu24 commented on GitHub (Dec 22, 2020):

I don't see it explicitly mentioned in this thread, but adding/setting "startingDirectory": "", for any particular profile in the settings.json will cause the behavior specified in https://github.com/microsoft/terminal/pull/3547 i.e. type wt in the explorer bar and start the default terminal profile in the current explorer directory.

hopefully this makes it clearer for people arriving here by Google or whatever.

@kenblu24 commented on GitHub (Dec 22, 2020): I don't see it explicitly mentioned in this thread, but adding/setting `"startingDirectory": "",` for any particular profile in the settings.json will cause the behavior specified in https://github.com/microsoft/terminal/pull/3547 i.e. type `wt` in the explorer bar and start the default terminal profile in the current explorer directory. hopefully this makes it clearer for people arriving here by Google or whatever.

claunia commented

@aborruso commented on GitHub (Aug 15, 2021):

Hi,
I would like to open Windows Explorer, write wt in the path bar and click ENTER to have my default system opened in that path (it's a debian on WSL2).

But when I run wt I have always as starting path, the user HOME, the ~ that for me is /home/aborruso
I have the same result if I run wt -d .

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"
            }
        ]
    }

@aborruso commented on GitHub (Aug 15, 2021): Hi, I would like to open Windows Explorer, write `wt` in the path bar and click <kbd>ENTER</kbd> to have my default system opened in that path (it's a debian on WSL2). But when I run `wt` I have always as starting path, the user HOME, the `~` that for me is `/home/aborruso` I have the same result if I run `wt -d .` Below my settings. How to start windows terminal from current explorer folder, running simply wt? Thank you ```json "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" } ] } ``` ![image](https://user-images.githubusercontent.com/30607/129486612-3dde7bb4-32d2-41d1-879e-c00cec79d33f.png)

claunia commented

@DHowett commented on GitHub (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.

@DHowett commented on GitHub (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.

claunia commented

@aborruso commented on GitHub (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

@aborruso commented on GitHub (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

claunia commented

@Zingam commented on GitHub (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.

@Zingam commented on GitHub (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.

claunia commented