Since <
for input redirection is not supported in PowerShell, use Get-Content
in a pipeline instead:
Get-Content evilwords.txt | python evil_61.py
Note: Adding the -Raw
switch - which reads a file as a single, multi-line string - would speed things up in principle (at the expense of increased memory consumption), but PowerShell invariably appends a newline to data piped to external programs, as of PowerShell 7.2 (see this answer), so the target program will typically see an extra, empty line at the end. Get-Content
's default behavior of line-by-line streaming avoids that.
Beware character-encoding issues:
Get-Content
, in the absence of an -Encoding
argument, assumes the following encoding:
- Windows PowerShell (the built-into-Windows edition whose latest and final version is 5.1): the active ANSI code page, which is implied by the active legacy system locale (language for non-Unicode programs).
- PowerShell (Core) 7+: (BOM-less) UTF-8
On passing the lines through the pipeline, they are (re-)encoded based on the encoding stored in the $OutputEncoding
preference variable, which defaults to:
- Windows PowerShell: ASCII(!)
- PowerShell (Core) 7+: (BOM-less) UTF-8
As you can see, only PowerShell (Core) 7+ exhibits consistent behavior, though, unfortunately, as of PowerShell Core 7.2.0-preview.9, this doesn't yet extend to capturing output from external programs, because the encoding that controls the interpretation of received data, stored in [Console]::OutputEncoding]
, still defaults to the system's active OEM code page - see GitHub issue #7233.