Why does console size affects powershell redirection

Start with a narrow (50 characters) console window and run:

PS C:\temp> ps >ps.txt
PS C:\temp> (gc .\ps.txt | %{ $_.length } | measure-object -max).maximum
49
PS C:\temp>

Then make your console window full screen and run it again:

PS C:\temp> ps >ps.txt
PS C:\temp> (gc .\ps.txt | %{ $_.length } | measure-object -max).maximum
157
PS C:\temp>

Why does the console size affect output written to (redirected to) a file?

Is there a way to not see this behavior? I’d like my scripts to generate the same file data regardless of the size of the console they happen to be invoked in.

In Linux/bash, you can only query the window dimensions thru a tty handle, and when you redirect an operation to a file handle, that query fails, so all console/window processing (even pagers) get disabled… But with powershell, it seems file redirection still leaves the underlying operation inherently knowing (and using!) the console handle (that is not even involved in the write!).

Thanks for any explanation!

PS You can see the same behavior with write-information “…” 6>file, but not with write-output “…” >file – I am not sure why…

[vexx32]

Opened #15474 to track the future enhancement. 🙂

[vexx32]

Wow, that is totally nice thank you – this makes everything good for me, without resizing my window!!!

$PSDefaultParameterValues['out-file:width'] = 1000

Thank you again!

PS is there a list of default parameter values documented anywhere? How did you find this?

Basically it can be used to set any cmdlet/function’s default parameter values for the session. The syntax is $PSDefaultParameterValues['Cmdlet-Name:ParameterName'] = $value – and note that you can use wildcards for cmdlet or parameter names, so for example you could enable -Force by default for all *Item commands (get-item, get-childitem, etc) with: $PSDefaultParameterValues['*-*Item:Force'] = $true

That it works for > is basically an implementation detail because > is calling the Out-File cmdlet implicitly.