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:
1234567890123456789012345678901234567890123456789012345678901234567890123456789
01234567890
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.
Backstory
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…