When Powershell writes to standard out, and there is now redirection in the Powershell script itself, it will assume that it writes to a console. Because of this, it kindly breaks lines if they are longer than 80 characters. So, given the following powershell file (.ps1):
# line-gunk.ps1 "123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890"
If you run this Powershell file from the Windows command line, and redirects output to a file:
C:\>@powershell -file .\line-gunk.ps1 > foo.txt
Then you will get:
However, if you do the redirection in Powershell, it’s fine:
PS C:\> .\line-gunk.ps1 > bar.txt
A näive fix to this, would be to change your script to use
Write-Host to explicity write the text to the console. However, I consider this a bad practice because it would restrict the usage of your script as you could not manipulate the output further if reusing the script. I found this entry on stackoverflow which provides a better solution. Going back to the original script, here is a fixed one that worked for me:
# line-gunk-fixed.ps1 $Host.UI.RawUI.BufferSize = New-Object Management.Automation.Host.Size(500, 25) "123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890"
Notice that I used the simplifed version from the stackoverflow entry, which might not work in all circumstances.
How did I come across this problem? I running Powershell build scripts in TeamCity and I was trying to report the build progress back to TeamCity. However, it somehow did not work. I then discovered that the status messages written by my script were broken by the line breaks, rendering them useless…