Terminal locks its starting directory; perhaps it shouldn&#39;t do that? #7603

@ghost commented on GitHub (Apr 23, 2020):

Locking the dir that a shell is currently using be is reasonable. Keeping the wt starting dir locked as long as wt is running is awkward

Xonsh in particular allows you to keep the dir unlocked.

Get Outlook for Androidhttps://aka.ms/ghei36

@ghost commented on GitHub (Apr 23, 2020): Locking the dir that a shell is currently using be is reasonable. Keeping the wt starting dir locked as long as wt is running is awkward Xonsh in particular allows you to keep the dir unlocked. Get Outlook for Android<https://aka.ms/ghei36>

claunia commented

@DHowett-MSFT commented on GitHub (Apr 23, 2020):

I don't disagree, but I do somewhat wonder how this'll interact with future uses of profiles with "startingDirectory": ".". Like: WT can move out of the directory it's in (since I think we're only locking it by virtue of it being our process's CWD), but then any new tab spawned with a profile set up like that will spawn in the wrong directory. We would need to pre-resolve all startingDirectories against the WD at the time of first settings load.

Then, at least those new tabs would error out ("can't find directory") instead of pointing at the wrong directory ...

@DHowett-MSFT commented on GitHub (Apr 23, 2020): I don't disagree, but I do somewhat wonder how this'll interact with _future_ uses of profiles with `"startingDirectory": "."`. Like: WT can move out of the directory it's in (since I think we're only locking it by virtue of it being our process's CWD), but then any new tab spawned with a profile set up like that will spawn in the wrong directory. We would need to pre-resolve all startingDirectories against the WD at the time of _first settings load_. Then, at least those new tabs would error out ("can't find directory") instead of pointing at the wrong directory ...

claunia commented

@ghost commented on GitHub (Apr 27, 2020):

That sounds completely reasonable to me.

@ghost commented on GitHub (Apr 27, 2020): That sounds completely reasonable to me.

claunia commented

@ghost commented on GitHub (Apr 27, 2020):

FWIW:
cmd does not lock the dir when it leaves (I created a new dir, started a new CMD in that dir, had the new cmd do a "cd ..", and then deleted the new dir no problem)

powershell does lock the directory (I created a new dir is PS, cd'd to that new directory started powershell.exe in that new dir, had the original PS do a "cd ..", and then had the NEW powershell instance do a "cd ..", and was NOT able to delete the new dir.)
(I had the new ps.exe do an exit and was able to delete the new dir no problem which makes me very confident that the ps.exe was holding that dir open)

bash (from Git Bash - MinGW64) does not lock the current directory. At least, I was able to start a new bash process in the background ( bash & ) in a new dir, then switch back to my original bash process, have it cd out of the new dir, and then delete the new dir no problem.

What was really weird is that the child bash kept it's current working directory as being the folder I'd just deleted. When I asked it to do an 'ls' it reasonably said ls: cannot open directory '.': No such file or directory

@ghost commented on GitHub (Apr 27, 2020): FWIW: cmd does not lock the dir when it leaves (I created a new dir, started a new `CMD `in that dir, had the new cmd do a "`cd ..`", and then deleted the new dir no problem) powershell does lock the directory (I created a new dir is PS, `cd`'d to that new directory started powershell.exe in that new dir, had the original PS do a "`cd ..`", and then had the NEW powershell instance do a "`cd ..`", and was NOT able to delete the new dir.) (I had the new ps.exe do an exit and was able to delete the new dir no problem which makes me very confident that the ps.exe was holding that dir open) bash (from Git Bash - MinGW64) does not lock the current directory. At least, I was able to start a new bash process in the background ( ` bash &` ) in a new dir, then switch back to my original bash process, have it `cd `out of the new dir, and then delete the new dir no problem. What was really weird is that the child bash kept it's current working directory as being the folder I'd just deleted. When I asked it to do an 'ls' it reasonably said `ls: cannot open directory '.': No such file or directory`

claunia commented

@DHowett-MSFT commented on GitHub (May 1, 2020):

I'm throwing this one on the backlog as a "Help Wanted" bug; We need to figure out the right thing to do here and how that plays with the user's profile settings and what an appropriate fallback looks like.

@DHowett-MSFT commented on GitHub (May 1, 2020): I'm throwing this one on the backlog as a "Help Wanted" bug; We need to figure out the right thing to do here and how that plays with the user's profile settings and what an appropriate fallback looks like.

claunia commented

@ghost commented on GitHub (May 1, 2020):

I may try to look at this myself. Obviously anyone else who's interested feel free to jump in.

Especially since I'm pretty busy until, like, August :)

Thanks for looking at this @DHowett-MSFT!

@ghost commented on GitHub (May 1, 2020): I may try to look at this myself. Obviously anyone else who's interested feel free to jump in. Especially since I'm pretty busy until, like, August :) Thanks for looking at this @DHowett-MSFT!

claunia commented

@zadjii-msft commented on GitHub (Dec 9, 2021):

You know what, there's actually another issue on the repo that's effectively the same thing: #10849. Both threads have great discussion.

@zadjii-msft commented on GitHub (Dec 9, 2021): You know what, there's actually another issue on the repo that's effectively the same thing: #10849. Both threads have great discussion.

claunia commented

@danielniccoli commented on GitHub (Jun 7, 2022):

When you configure a profile to include this:
"startingDirectory" : ".",
and then set up the right-click "Start Windows Terminal Here" functionality in Windows Explorer to start a wt instance in any > folder you get to create Terminal instances quickly and conveniently.

But, if you get done with that folder and want to delete it then you need to close wt first.

I have not set startingDirectory in my settings.json file, and still encounter this bug.

powershell does lock the directory (I created a new dir is PS, cd'd to that new directory started powershell.exe in that new dir, had the original PS do a "cd ..", and then had the NEW powershell instance do a "cd ..", and was NOT able to delete the new dir.) (I had the new ps.exe do an exit and was able to delete the new dir no problem which makes me very confident that the ps.exe was holding that dir open)

I cannot reproduce this behaviour. When I create a folder C:\temp\x, right-click that folder and select "Open PowerShell window here" and then change the directory to the parent, I can immediately delete that folder.

I'm on Windows 10, 21H2. But I know that this was always working like that for previous Windows version as well.

@danielniccoli commented on GitHub (Jun 7, 2022): > When you configure a profile to include this: > "startingDirectory" : ".", > and then set up the right-click "Start Windows Terminal Here" functionality in Windows Explorer to start a wt instance in any > folder you get to create Terminal instances quickly and conveniently. > > But, if you get done with that folder and want to delete it then you need to close wt first. I have not set `startingDirectory` in my `settings.json` file, and still encounter this bug. > powershell does lock the directory (I created a new dir is PS, `cd`'d to that new directory started powershell.exe in that new dir, had the original PS do a "`cd ..`", and then had the NEW powershell instance do a "`cd ..`", and was NOT able to delete the new dir.) (I had the new ps.exe do an exit and was able to delete the new dir no problem which makes me very confident that the ps.exe was holding that dir open) I cannot reproduce this behaviour. When I create a folder `C:\temp\x`, right-click that folder and select "Open PowerShell window here" and then change the directory to the parent, I can immediately delete that folder. ![image](https://user-images.githubusercontent.com/2971735/172368775-824dec9d-0368-4121-adf9-66e2158439f7.png) I'm on Windows 10, 21H2. But I know that this was always working like that for previous Windows version as well.

claunia commented

@danielniccoli commented on GitHub (Jun 7, 2022):

I don't disagree, but I do somewhat wonder how this'll interact with future uses of profiles with "startingDirectory": ".". Like: WT can move out of the directory it's in (since I think we're only locking it by virtue of it being our process's CWD), but then any new tab spawned with a profile set up like that will spawn in the wrong directory. We would need to pre-resolve all startingDirectories against the WD at the time of first settings load.

Then, at least those new tabs would error out ("can't find directory") instead of pointing at the wrong directory ...

The bug also happens, when you don't have startingDirectory in your settings.json. So that train of thought, while helpful in that other case, doesn't help when startingDirectoryis unset.

If you ask me, the behaviour could be as simple as: If the defined (or undefined for that matter) starting directory does not exist, fallback to $env:USERPROFILE. Then there is no need to lock that directory.

@danielniccoli commented on GitHub (Jun 7, 2022): > I don't disagree, but I do somewhat wonder how this'll interact with _future_ uses of profiles with `"startingDirectory": "."`. Like: WT can move out of the directory it's in (since I think we're only locking it by virtue of it being our process's CWD), but then any new tab spawned with a profile set up like that will spawn in the wrong directory. We would need to pre-resolve all startingDirectories against the WD at the time of _first settings load_. > > Then, at least those new tabs would error out ("can't find directory") instead of pointing at the wrong directory ... The bug also happens, when you don't have `startingDirectory` in your settings.json. So that train of thought, while helpful in that other case, doesn't help when `startingDirectory`is unset. If you ask me, the behaviour could be as simple as: If the defined (or undefined for that matter) starting directory does not exist, fallback to `$env:USERPROFILE`. Then there is no need to lock that directory.

claunia commented

@SpL1Ne commented on GitHub (Jun 8, 2022):

I cannot reproduce this behaviour.

I can with both Powershell 5 and 7.
Created folder manually in explorer, started powershell and tried to remove folder. Not with both powershells at the same time of course.

@SpL1Ne commented on GitHub (Jun 8, 2022): > I cannot reproduce this behaviour. I can with both Powershell 5 and 7. Created folder manually in explorer, started powershell and tried to remove folder. Not with both powershells at the same time of course. <details> ![2022-06-08_18-39-31](https://user-images.githubusercontent.com/8836461/172659936-23ca15a4-267f-4b4e-aca4-0a569dc71621.png) ![2022-06-08_18-40-17](https://user-images.githubusercontent.com/8836461/172659945-f056da95-183e-4897-bf58-b297aa39baa0.png) </details>

claunia commented

@danielniccoli commented on GitHub (Jun 8, 2022):

@SpL1Ne How do you open PS? Same way as I did?

@danielniccoli commented on GitHub (Jun 8, 2022): @SpL1Ne How do you open PS? Same way as I did?

claunia commented

https://user-images.githubusercontent.com/8836461/172722788-6e54ebd9-5c20-4c6a-8d32-a5c873757ca4.mp4

@SpL1Ne commented on GitHub (Jun 8, 2022):

@danielniccoli I don't have "open powershell here" on right-click so I just typed powershell.exe and pwsh into explorer address bar.
Edit: this video of me repeating steps from answer above which you quoted:

@SpL1Ne commented on GitHub (Jun 8, 2022): @danielniccoli I don't have "open powershell here" on right-click so I just typed `powershell.exe` and `pwsh` into explorer address bar. Edit: this video of me repeating steps from answer above which you quoted: <details> https://user-images.githubusercontent.com/8836461/172722788-6e54ebd9-5c20-4c6a-8d32-a5c873757ca4.mp4 </details>

claunia commented

@danielniccoli commented on GitHub (Jun 10, 2022):

Then there are differences here.

Open powershell.exe or pwsh.exe via context menu does not lock the directory.
Open wt.exe via context menu does lock the directory.
Open powershell.exe or pwsh.exe via address bar does lock the directory.

Option 1 is clearly supreme 😆

@danielniccoli commented on GitHub (Jun 10, 2022): Then there are differences here. 1. Open powershell.exe or pwsh.exe via context menu does **not** lock the directory. 2. Open wt.exe via context menu does lock the directory. 3. Open powershell.exe or pwsh.exe via address bar does lock the directory. Option 1 is clearly supreme 😆

claunia commented