eizedev
fix: relative path handling in Find-Item
By default if you pass a relative path to the .NET APIs, it will use [Environment]::CurrentDirectory as its base, not your actual PowerShell working directory.
The problem is that the two are almost never the same.
This changes it so that the entry path is resolved by PowerShell, not .NET.
Description
This resolves relative paths to absolute in PowerShell's working directory context instead of .NET's.
By default if you pass a relative path to the .NET APIs, it will use [Environment]::CurrentDirectory as its base, not your actual PowerShell working directory.
The problem is that the two are almost never the same.
This changes it so that the entry path is resolved by PowerShell, not .NET, by using PSCmdlet.GetResolvedProviderPathFromPSPath to resolve the path.
Related Issue
#19
Motivation and Context
It lets me specify relative paths to Find-Item.
How Has This Been Tested?
Ran Find-Item manually:
| How | Example | Result |
|---|---|---|
| without a specified path | Find-Item |
Works same as before |
| with a relative path | Find-Item foo |
Searches $PWD\foo instead of $HOME\foo |
| with an absolute path | Find-Item D:\github\cdonnellytx\foo |
Works same as before |
| with a PSPath | Find-Item 'Microsoft.PowerShell.Core\FileSystem::D:\github\cdonnellytx\foo' |
Searches as if it was passed D:\github\cdonnellytx\foo |
Screenshots (if appropriate):
Types of changes
- [x] Bug fix (non-breaking change which fixes an issue)
- [ ] New feature (non-breaking change which adds functionality)
- [ ] Breaking change (fix or feature that would cause existing functionality to change)
Checklist:
- [ ] My code follows the code style of this project.
- [ ] My change requires a change to the documentation.
- [ ] I have updated the documentation accordingly.
- [ ] I have read the CONTRIBUTING document.
- [ ] I have added tests to cover my changes.
- [ ] All new and existing tests passed.
Definitely not finished yet, found a fun bug wherein if the path doesn't resolve, the Path variable is never updated, and so a failed path ends up looking in $HOME anyway.
I'll fix it and will ensure there are tests before going live with this.
@cdonnellytx sorry, i completely missed your issue and pull request. also i didn't looked into this repository for a long time. I will check/review, fix some bugs in the deployment process and get back to you in the next days.
@cdonnellytx
When using the provider, since -Path can include wildcards (e.g., C:\Users\*\Documents) and is expanded to multiple root paths by the provider we could get problems. So i decided to only use the first element of the array for now.
But you gave me a great idea to simply incorporate the Linux equivalent of wildcards in the path. I will release a new version soon with your change and a subsequent extension from me (including further changes that I had not yet published on Github/Gallery).