Powershell Get-Content failing spuriously

Question

I have a fairly simple PS script that was working perfectly, and now has suddenly started giving errors. I have narrowed the problem portion to a couple of Get-Content statements. Here's what the affected part of the script looks like:

$pathSource = "D:\FileDirectory"
Set-Location -Path $pathSource
Get-Content -Encoding UTF8 -Path FilesA*.txt | Out-File -Encoding ASCII FilesA_Digest.txt
Get-Content -Encoding UTF8 -Path FilesB*.txt | Out-File -Encoding ASCII FilesB_Digest.txt

This part of the script gathers up a collection of like-named files and concatenates them into a single text file for uploading to an FTP site. The Get-Content/Out-File was needed as the original files are encoded incorrectly for the FTP site. The script was working perfectly, running once each night for several weeks. Now, it gets the following error when the Get-Content statements are reached:

Get-Content : A parameter cannot be found that matches parameter name 'Encoding'.
At D:\FileDirectory\Script.ps1

Environment is Windows Server 2016. I've tried different variations on the Get-Content parameters, but nothing has worked. I know there is a bug that affects network-mapped drives, but that's not the case here -- all files are local.

Any ideas/suggestions?

Answer 1

The only plausible explanation I can think of is that a custom Get-Content command that lacks an -Encoding parameter is shadowing (overriding) the standard Get-Content cmdlet in the PowerShell session that's executing your script.

To demonstrate:

# Define a custom Get-Content command (function) that accepts only 
# a (positional) -Path parameter, not also -Encoding.
function Get-Content { [CmdletBinding()] param([string] $Path) }

# Now try to use Get-Content -Encoding
Get-Content -Encoding Utf8 FilesA*.txt

You'll see the same error message as in your question.

Use Get-Command Get-Content -All to see all commands named Get-Content, with the effective command listed first.

Then examine where any custom commands may come from; e.g., your $PROFILE script may contain one.

To rule out $PROFILE as the culprit, start PowerShell without loading the profile script and examine Get-Content then:

powershell -noprofile  # Windows PowerShell
pwsh -noprofile        # PowerShell Core

A simple way to rule out custom overrides ad hoc is to call a command by its module-qualified name:

Microsoft.Powershell.Management\Get-Content ...

You can determine a built-in cmdlet's module name of origin as follows:

PS> (Get-Command Get-Content -All)[-1].ModuleName
Microsoft.PowerShell.Management

In a pinch you can also infer the originating module name from the URL of the help topic:

• Googling Get-Content will take you to https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.management/get-content - note how the cmdlet's module name, microsoft.powershell.management (case doesn't matter), is the penultimate (next to last) URI component.

Answer 2

It seems an issue with the out command. Can you please try below code :

$pathSource = "D:\FileDirectory"
Set-Location -Path $pathSource
Get-Content -Encoding UTF8 -Path FilesA*.txt | Set-Content  -Encoding ASCII -path FilesA_Digest.txt
Get-Content -Encoding UTF8 -Path FilesB*.txt | Set-Content  -Encoding ASCII -path FilesB_Digest.txt

Answer 3

Well, I don't know why it failed, but I can say that I have completely re-written the script and now it works. I have to note that, given the errors that were occurring, I also don't know why it is now working.

I am using the exact same calls to the Get-Content commandlet, with the -Encoding parameter and the pipe to Out-File with its own -Encoding parameter. I am doing the exact same actions as the previous version of the script. The only part that is significantly different is the portion that performs the FTP transfer of the processed files. I'm now using only PowerShell to perform the transfer rather than CuteFTP and it all seems to be working correctly.

Thanks to everyone who contributed.

Cheers Norm

Answer 4

Not sure if it helps, but I was running into the same with:

$n = ni '[hi]' -value 'some text'
gc $n -Encoding Byte
$f = ls *hi*
$f.where{$_.name -eq '[hi]'}.Delete()

also looks like there's already a chain of SOs about this known bug see this answer