Although it might be a grey area, this is a breaking change as it changes how the arguments passed to WorkingDirectory, RedirectStandardError, RedirectStandardInput, and RedirectStandardOutput get resolved. Need the committee to weigh in.

@PowerShell/powershell-committee reviewed this, we propose that instead of always treating it as a literal, we would check if the path exists as a literal use it, otherwise fallback to the current behavior

How?

Working Directory by definition cannot be a useful wildcarded path, which can usually be assumed to exist. If you have an incomplete path, you can tab complete the rest. If you really need wildcards for any of these, you have Get-Item available.

Redirection paths typically won't exist for most use cases (again, no use for wildcards if the path doesn't exist), but as I understand it the cmdlet isn't capable of writing to multiple paths anyway, can it?

Rain Sallow (/u/ta11ow) (@vexx32) Agreed. In fact, when I force the command to match multiple matches for output redirection, the command says: Start-Process: Cannot perform operation because the path resolved to more than one file. This command cannot operate on multiple files.

Steve Lee (@SteveL-MSFT) Certainly can't say that makes a lot of sense to me, but I can adjust the code if that's the verdict. Should the documentation be updated to say it "Sort Of" supports wildcards? Thoughts on redirection parameters as Rain Sallow (/u/ta11ow) (@vexx32) mentions?

Redirection paths typically won't exist for most use cases

I agree that in most use cases the redirection files for standard output/error don't exist beforehand. But -RedirectStandardInput by definition requires an existing file.
Even for -RedirectStandardError and -RedirectStandardOutput, it's hard to say the current wildcard behavior is not being used at all. I can imagine a CI system where a new log file is created every day in the format ci-log-<date>.txt and output/error of a process is supposed to be written to that log file. For this hypothetical scenario, it's natural to use a wildcard like ci-log-*.txt for those 2 parameters (only one file, which is created on that day, will be matched). I think that's why the committee decide to suggest a more conservative (less breaking) behavior.

Working Directory by definition cannot be a useful wildcarded path, which can usually be assumed to exist.

One can create two directories named [a]b and ab. [a]b is a valid wildcard that matches ab. Again, I think the committee's suggestion is more conservative (less breaking).

Dongbo Wang (@daxian-dbw) Based on your examples I can conclude that we should first make wildcard check and then literal.

Ilya (@iSazonov) that's a valid point and would seem to be less breaking as any existing usage expecting wildcard matching would continue to work

Ilya (@iSazonov) Steve Lee (@SteveL-MSFT) Dongbo Wang (@daxian-dbw) Rain Sallow (/u/ta11ow) (@vexx32) It appears that PathUtils.ResolvePath() is not positioned well to do the sort of trial-and-error that's discussed. Instead of biting off that task right now, what I've done adjusted this PR's scope to address the originally reported behavior that was causing Start-Process to fail when WorkingDirectory is not specified but the current directory is set to a path that contains wildcard-type characters. (e.g. Set-Location 'C:\Path[]'; Start-Process cmd.exe was failing). I believe this change is non-breaking and should be non-controversial.

I think there are additional problems here and definitely some holes in our testing. As the following shows:

Describe "Should be able to set location to name with wild card" {
    BeforeAll {
        $testCases = @{ Name = 'foo[' },@{ Name = 'foo]' },@{ Name = 'foo[]' }, @{ Name = 'foo?' }, @{ Name = 'foo[?]' },
            @{ Name = 'foo[*]' },@{ Name = 'foo[*' },@{ Name = 'foo*]' }
    }

    It "Should be able to create and set the location to <Name>" -TestCases $testCases {
        param ( $Name )

        if ( $Name -match "\*" -and $IsWindows ) {
            Set-ItResult -Skipped -Because "'$Name' is not supported as directory name on Windows"
            return
        }
        
        $item = New-Item -Type Directory -Path ${TESTDRIVE}/$Name
        $item.Name | Should -Be $Name
        
        $i = Get-Item -LiteralPath ${TESTDRIVE}/$Name
        $i.Name | Should -Be $Name

        $location = Get-Location
        try {
            Set-Location -LiteralPath ${TESTDRIVE}/$Name
            $sName = [System.IO.Path]::GetFileName((Get-Location ).Path)
            $sName | Should -Be $Name
        }
        catch {
            throw "Set-Location $Name Failed"
        }
        finally { 
            Set-Location -LiteralPath $location.Path
        }
    }
}

when run on my Mac, I get the following result

Describing Should be able to set location to name with wild card
  [+] Should be able to create and set the location to foo[ 36ms
  [+] Should be able to create and set the location to foo] 13ms
  [+] Should be able to create and set the location to foo[] 26ms
  [+] Should be able to create and set the location to foo? 28ms
  [+] Should be able to create and set the location to foo[?] 41ms
  [-] Should be able to create and set the location to foo[*] 56ms
    Expected strings to be the same, but they were different.
    Expected length: 6
    Actual length:   5
    Strings differ at index 4.
    Expected: 'foo[*]'
    But was:  'foo[]'
    18:         $i.Name | Should -Be $Name
    at <ScriptBlock>, /tmp/zap/tt.tests.ps1: line 18
  [-] Should be able to create and set the location to foo[* 17ms
    Expected strings to be the same, but they were different.
    String lengths are both 5.
    Strings differ at index 4.
    Expected: 'foo[*'
    But was:  'foo[]'
    18:         $i.Name | Should -Be $Name
    at <ScriptBlock>, /tmp/zap/tt.tests.ps1: line 18
  [-] Should be able to create and set the location to foo*] 20ms
    Expected strings to be the same, but they were different.
    String lengths are both 5.
    Strings differ at index 3.
    Expected: 'foo*]'
    But was:  'foo[]'
    18:         $i.Name | Should -Be $Name
    at <ScriptBlock>, /tmp/zap/tt.tests.ps1: line 18

The files present in $TESTDRIVE are:

PS> ls $TESTDRIVE |ft -auto

    Directory: /private/tmp/ea03bb1e-4ae5-46b7-af36-6341e4015b20

UnixMode   User  Group  LastWriteTime Size Name
--------   ----  -----  ------------- ---- ----
drwxr-xr-x james wheel 4/8/2020 13:27   64 foo?
drwxr-xr-x james wheel 4/8/2020 13:27   64 foo[
drwxr-xr-x james wheel 4/8/2020 13:27   64 foo[?]
drwxr-xr-x james wheel 4/8/2020 13:27   64 foo[]
drwxr-xr-x james wheel 4/8/2020 13:27   64 foo[*
drwxr-xr-x james wheel 4/8/2020 13:27   64 foo[*]
drwxr-xr-x james wheel 4/8/2020 13:27   64 foo]
drwxr-xr-x james wheel 4/8/2020 13:27   64 foo*]

James Truher (@JamesWTruher) Yeah, I suspected that there are going to be these sort of wildcard processing issues I located in Start-Process in other cmdlets as well. Unless you've already dove in, I'll look into the behavior you noted as a separate PR (unless you think it's somehow related to this specific fix for Start-Process).

Note, for Windows your match should be more like $Name -match '[<>:"/\|?*]' -and $IsWindows since none of these characters are supported. When these illegal characters are eliminated, it passes on Windows but only the three test cases are executed. I'll try on MacOS later.

The more I think about wildcards in the scenario the less I like it. I'd prefer literal paths - it is unnatural behavior to expand wildcards for these paths. I can’t imagine that someone selects a working directory by wildcard, and especially a redirect file. It is unreliable and unpredictable.

James Truher (@JamesWTruher) Reproduced your Mac results. Set-Location -LiteralPath definitely doesn't handle processing '*' characters very well whereas the native shells do just fine. I do believe this is a separate issue though from the one this PR addresses though. Will look at the underlying code tomorrow to verify...

James Truher (@JamesWTruher) I confirmed the behavior you reported is a different issue and is related to the code called within Set-Location that's responsible for case normalization. I have a potential fix and will submit that separately. Please proceed with adjudicating this PR as-is.

Update: Noted behavior is corrected in #12294. This includes an enhanced version of your test script.

@PowerShell/powershell-committee reviewed this, we agree that an implicit WorkingDirectory should be literal and never glob, so the targeted fix is fine for this PR (not a comment on the code itself but the intent).

This pull request has been automatically marked as Review Needed because it has been there has not been any activity for 7 days.
Mainainer, Please provide feedback and/or mark it as Waiting on Author

Dongbo Wang (@daxian-dbw) I think the PR is ready to merge.

This pull request has been automatically marked as Review Needed because it has been there has not been any activity for 7 days.
Mainainer, Please provide feedback and/or mark it as Waiting on Author

Bryan Berns (@NoMoreFood) Thanks for your contribution!

🎉v7.1.0-preview.4 has been released which incorporates this pull request.:tada:

Handy links:

• Release Notes