Find-Item: relative paths are resolved to the wrong directory

[cdonnellytx]

When specifying a relative path to -Path, it is resolved to the wrong current directory, frequently resulting in errors like the following:

Exception calling "EnumerateFileSystemEntries" with "3" argument(s): "Could not find a part of the path C:\Users\cdonnelly\foo.

Expected Behavior

Find-Item -Path "foo" should crawl "$PWD\foo".

Current Behavior

Find-Item -Path "foo" crawls "$([System.Environment]::CurrentDirectory)\foo", throwing an error if it is not found.

Possible Solution

Resolve the path using PowerShell APIs. See #18 .

Steps to Reproduce (for bugs)

1. Set-Location to any filesystem directory that isn't [System.Environment]::CurrentDirectory. In practice this means "not $HOME".
2. Call Find-Item foo where foo is a relative path that exists in the test location but ideally not in $HOME either.

A more formal example:

# we need a temporary dir, unfortunately APIs only let us create temporary files.
# Fortunately I have a workaround.
New-TemporaryFile | % { rm $_; mkdir $_ } | Set-Location

# now we need a child with a unique name too.  Using a Guid since it **should** be unique.
$path = [Guid]::NewGuid().ToString()
mkdir $path

# Put a file in the new directory for good measure
echo '' > (Join-Path ${path} 'foo.txt')

# Now find.
Find-Item -Path $path

Context

Your Environment

• Module version used: 0.3.6
• Operating System and PowerShell version: Microsoft Windows 10.0.26100 (24H2) x64, PowerShell 7.4.x and 7.5.0.

[eizedev]

I merged the pull request and made additional enhancements afterwards. Thanks @cdonnellytx for the issue/pull request and the idea using the PSProvider!

(Version 0.7.0 should be released soon)