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

fix: relative path handling in Find-Item #18

Draft
wants to merge 3 commits into
base: master
Choose a base branch
from

Conversation

cdonnellytx
Copy link

@cdonnellytx cdonnellytx commented Jan 30, 2025

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

  • 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.

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.
@cdonnellytx
Copy link
Author

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.

PowerShell expects things to be written to Write-Error so they can be handled in a standard fashion based on the ErrorActionPreference.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant