Powershell does not open in current directory if its name contains a left square bracket (wildcard)

[louistio]

Steps to reproduce

C:\>mkdir "[T]est"

C:\>cd "[T]est"

C:\[T]est>pwsh.exe
PowerShell v6.0.0-rc.2
Copyright (c) Microsoft Corporation. All rights reserved.

https://aka.ms/pscore6-docs
Type 'help' to get help.

PS C:\Programs\PowerShell\6.0.0-rc.2>

1. Make a directory called "[T]est".
2. Run cmd (or powershell) and cd to the directory.
3. Run powershell.

Expected behavior

Powershell always starts in the folder the parent process runs it in, regardless of the name of the folder.

Actual behavior

3 observed behaviors:
- Powershell starts in its home directory if the folder has left and right brackets. (ex: "Te[st]")
- Powershell starts in C:\ if the folder only has left brackets. (ex: "Te[st")
- Powershell starts in the current directory if it only has right brackets. (ex: "Te]st")

Environment data

> $PSVersionTable
Name                           Value
----                           -----
PSVersion                      6.0.0-rc.2
PSEdition                      Core
GitCommitId                    v6.0.0-rc.2
OS                             Microsoft Windows 10.0.16299
Platform                       Win32NT
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0...}
PSRemotingProtocolVersion      2.3
SerializationVersion           1.1.0.1
WSManStackVersion              3.0

Additional Information

Hope this isn't a known issue, I've experienced it myself both when starting powershell from cmd and from Visual Studio Code ("Open in Terminal"). I've seen it discussed a little bit here. It might be related to Issue #4726. Hope we can see this fixed.

[iSazonov]

@mklement0 Could you please comment the Issue?

[mklement0]

@iSazonov: The problem sounds closely related to #4726, as @Enchanted13 has already pointed out.

[KillyMXI]

Hello. Author of the mentioned page here. Recently I ran into another issue, so I made a follow-up post.

Until this issue is fixed, the only reliable way to open PowerShell in any folder would be some proxy application, doing all the required escaping, I think.

[louistio]

@KillyMXI Hey, great follow-up post, I think this shows that native workarounds aren't really reliable for all the possible edge cases. A third party solution would be possible, but I really hope we can see these issues being fixed in powershell itself in the near future!

[SteveL-MSFT]

Reverting the previous change due to side effects. Will have to revisit this later.

[JamesWTruher]

just posted PR #7240 for this