-
Notifications
You must be signed in to change notification settings - Fork 8.3k
Fix for issue 5752: pwsh cannot start in a directory with a name that includes a wildcard #7240
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
Changes from all commits
25670e7
206ca71
aa76ace
7b3e866
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -683,3 +683,27 @@ Describe "Pwsh exe resources tests" -Tag CI { | |
| $psversiontable.os | Should -MatchExactly "$($osversion.Major).$($osversion.Minor)" | ||
| } | ||
| } | ||
|
|
||
| Describe 'Pwsh startup in directories that contain wild cards' -Tag CI { | ||
| BeforeAll { | ||
| $powershell = Join-Path -Path $PsHome -ChildPath "pwsh" | ||
| $dirnames = "[T]est","[Test","T][est","Test" | ||
| $testcases = @() | ||
| foreach ( $d in $dirnames ) { | ||
| $null = New-Item -type Directory -path "${TESTDRIVE}/$d" | ||
| $testcases += @{ Dirname = $d } | ||
| } | ||
| } | ||
|
|
||
| It "pwsh can startup in a directory named <dirname>" -testcases $testcases { | ||
| param ( $dirname ) | ||
| try { | ||
| Push-Location -LiteralPath "${TESTDRIVE}/${dirname}" | ||
| $result = & $powershell -c '(Get-Item .).Name' | ||
|
Collaborator
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Should we use cmdlet? Maybe better .Net method to get current directory or -LiteralPath?
Collaborator
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. it really doesn't matter, does it?
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I agree, maybe use $result = & $powershell -c '([Environment]::CurrentDirectory)'
Collaborator
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. also, I want to check only the name, ason some systems, Environment.CurrentDirectory will include a symlink which is a problem because PS does not, I'm I need to call split-path, I can use this form just as well.
Collaborator
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Since we are testing PowerShell, it would makes sense to use PowerShell i.e. the way Jim has written it rather then calling .NET. Why do you think it should be a .NET call? Is there some reason not to use native PowerShell capabilities?
Collaborator
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. My misunderstanding is that we use |
||
| $result | Should -BeExactly $dirname | ||
| } | ||
| finally { | ||
| Pop-Location | ||
| } | ||
| } | ||
| } | ||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
(style) Maybe it's just my OCD, by why configuring providerContext inside try block rather than right after initialization?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I wanted the two operations to be visually close, putting the assignment in the block did that for me