Path parameter is intepreting wildcard characters

[Wardrop]

I ran into an issue today where a filename with the structure "xxxx [xxxx.pdf" failed to upload using Set-SFTPItem with the error: The specified wildcard character pattern is not valid: xxxx [xxxx.pdf. Same applies to Remove-SFTPItem and possibly other commands. I ended up having to escape the filename with [Management.Automation.WildcardPattern]::Escape().

Is this the intended default behaviour? It was surprising to me as I'm reading files off the local disk using Get-ChildItem so wasn't esxpecting the path to parsed for wildcard characters. Perhaps the default behaviour should be changed and a new parameter be added to turn on wildcard passing (e.g. -UseWildcards)?

I'll let you decide, but just making you aware as the current behaviour is surprising and can be a little incideous as until you run into a bit of an oddball filename you're under the assumption that everything is rock solid.

[darkoperator]

Yes, that is expected behavior, in case you have files with those special characters you can also quote the full path with single quotes. I will update the help information so it shows that wildcards are accepted by the parameter.

[Wardrop]

@darkoperator Thanks for the quick reply.

How would I wrap the value in single quotes if I'm passing the value in as a variable? If I was typing it in as a string literal I wouldn't be so surprised about the wildcard behaviour, but given I'm passing the value in as a variable it is quite surprising. E.g.

Set-SFTPItem -Path $sourceFile -Destination $targetDir

Are you suggesting I do something like this?

Set-SFTPItem -Path "'$sourceFile'" -Destination $targetDir

[darkoperator]

thats because I have a PS internal function resolve the path to the full path in case someone passes relative paths or mounts a drive using a PSDrive since PS uses an internal provider https://github.com/darkoperator/Posh-SSH/blob/master/Source/PoshSSH/PoshSSH/SetScpItem.cs#L100 Gona have to test that one out when I get a chance tomorrow, I did encounter that problem before and I simply renamed the files and avoided using those characters for STL files I was uploading to a machine,