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.