Skip to content
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

Open
nphmuller opened this issue May 17, 2019 · 38 comments · May be fixed by #3547

Comments

@nphmuller
Copy link

@nphmuller nphmuller commented May 17, 2019

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.

@msftbot msftbot bot added the Needs-Triage label May 17, 2019
@DHowett-MSFT

This comment has been minimized.

Copy link
Member

@DHowett-MSFT DHowett-MSFT commented May 17, 2019

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.

@nphmuller

This comment has been minimized.

Copy link
Author

@nphmuller 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

This comment has been minimized.

Copy link
Contributor

@fghzxm fghzxm commented 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?)

@nphmuller

This comment has been minimized.

Copy link
Author

@nphmuller 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

This comment has been minimized.

Copy link
Member

@DHowett-MSFT 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

This comment has been minimized.

Copy link
Contributor

@fghzxm 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).

@nphmuller

This comment has been minimized.

Copy link
Author

@nphmuller 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.

@zadjii-msft zadjii-msft added this to the Terminal Backlog milestone Jun 19, 2019
@ffes

This comment has been minimized.

Copy link

@ffes ffes commented 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

@fghzxm

This comment has been minimized.

Copy link
Contributor

@fghzxm fghzxm commented Jun 24, 2019

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

@ffes

This comment has been minimized.

Copy link

@ffes ffes commented 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.

@bmlynarczyk

This comment has been minimized.

Copy link

@bmlynarczyk bmlynarczyk commented 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.

@twopoint71

This comment has been minimized.

Copy link

@twopoint71 twopoint71 commented 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.

@DHowett-MSFT

This comment has been minimized.

Copy link
Member

@DHowett-MSFT DHowett-MSFT commented Aug 8, 2019

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

@joemaller

This comment has been minimized.

Copy link

@joemaller joemaller commented Aug 14, 2019

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

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

This comment has been minimized.

Copy link

@ipat8 ipat8 commented 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.)

@nsheaps

This comment has been minimized.

Copy link

@nsheaps nsheaps commented 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)

@Kaszaq

This comment has been minimized.

Copy link

@Kaszaq Kaszaq commented 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]

@akulbe

This comment has been minimized.

Copy link

@akulbe akulbe commented Sep 3, 2019

This answered a question for me too. 🙌🏻

@thisguychris

This comment has been minimized.

Copy link

@thisguychris thisguychris commented 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.

@fghzxm

This comment has been minimized.

Copy link
Contributor

@fghzxm fghzxm commented Sep 17, 2019

@thisguychris

This comment has been minimized.

Copy link

@thisguychris thisguychris commented Sep 17, 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

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

@thisguychris

This comment has been minimized.

Copy link

@thisguychris thisguychris commented Sep 17, 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

@thisguychris

This comment has been minimized.

Copy link

@thisguychris thisguychris commented 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.

@fghzxm

This comment has been minimized.

Copy link
Contributor

@fghzxm fghzxm commented Sep 19, 2019

@Daegalus

This comment has been minimized.

Copy link

@Daegalus Daegalus commented 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

@twopoint71

This comment has been minimized.

Copy link

@twopoint71 twopoint71 commented Sep 27, 2019

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

echo "cd" >> ~/.bashrc

@dlxeon

This comment has been minimized.

Copy link

@dlxeon dlxeon commented 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?

@zadjii-msft

This comment has been minimized.

Copy link
Member

@zadjii-msft zadjii-msft commented 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

This comment has been minimized.

Copy link
Member

@zadjii-msft zadjii-msft commented 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

@DHowett-MSFT

This comment has been minimized.

Copy link
Member

@DHowett-MSFT DHowett-MSFT commented 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.
@zadjii-msft

This comment has been minimized.

Copy link
Member

@zadjii-msft zadjii-msft commented 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 added a commit that referenced this issue Oct 4, 2019
@akunzai

This comment has been minimized.

Copy link

@akunzai akunzai commented Oct 5, 2019

Try "startingDirectory": "." for workaround.

see HERE for example.

@piotrpalek

This comment has been minimized.

Copy link

@piotrpalek piotrpalek commented 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.

@fle108

This comment has been minimized.

Copy link

@fle108 fle108 commented 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

@Ujang360

This comment has been minimized.

Copy link

@Ujang360 Ujang360 commented 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.

@zadjii-msft zadjii-msft self-assigned this Nov 12, 2019
@zadjii-msft zadjii-msft referenced a pull request that will close this issue Nov 12, 2019
2 of 2 tasks complete
@msftbot msftbot bot added the In-PR label Nov 12, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.