How do I avoid a linewrap in powershell output? Appearently powershell thinks the terminal is of limited size.

I call it like that:

ssh user@winsrv powershell -NonInteractive -NoLogo -File some.ps1

This causes the lines to be wrapped/truncated at 80 chars. Only powershell has this issue, the parent POSIX shell gets it right.

You can try setting the bufferwidth using [console]::bufferwidth. Create a profile and set the value to whatever you want. The profile path is generally 

C:\Users\<user>Documents\WindowsPowerShell\Microsoft.PowerShell_profile.ps1

If it doesn't exist create it and add the [console]::bufferwidth = <whatever> command.

Does that actually work for you?

Exception setting "bufferwidth": "The handle is invalid.
"
At
C:\Users\root\Documents\WindowsPowerShell\Microsoft.PowerShell_profile.ps1:1
char:1
+ [console]::bufferwidth = 0

You can't set a zero value by the looks of things, the max you could set would be

[console]::bufferwidth = 32766

The handle remains invalid, no matter what value is assigned.

Strange it works fine for me - 

PS H:\> [console]::bufferwidth = 32766
PS H:\> [console]::bufferwidth
32766

Does the error occur only when running your command line or does it happen even if you just open a powershell console.

Also, where is your output being directed, just to the console or are you redirecting it somewhere else?

• Edited by Braham20 22 hours 36 minutes ago

Works when I login via rdesktop and call it from cmd.exe.

So it looks like remote login is different from GUI login.

From the profile help - 

 PROFILES AND REMOTE SESSIONS      

    Windows PowerShell profiles are not run automatically in remote sessions,
    so the commands that the profileS add are not present in the remote session.
    In addition, the $profile automatic variable is not populated in remote sessions.    

    To run a profile in a session, use the Invoke-Command cmdlet.

    For example, the following command runs the CurrentUserCurrentHost profile from
    the local computer in the session in $s. 

        invoke-command -session $s -filepath $profile

    The following command runs the CurrentUserCurrentHost profile from the remote
    computer in the session in $s. Because the $profile variable is not populated,
    the command uses the explicit path to the profile.

        invoke-command -session $s {invoke-command "$home\Documents\WindowsPowerShell\Microsoft.PowerShell_profile.ps1"}

    After running this command, the commands that the profile adds to the session
    are available in $s.

Well, there are remote commands and remote commands. What you quoted is likely for the windows style login.

When launched from cygwin sshd the profile is executed because I see the errors.

I can't offer much more help I'm afraid. I've never used POSIX or cygwin and I don't have an environment I can test in. I suspect you're seeing the error because the output is being redirected but without access to the shell it's just a guess.

SSH and other remoting systems that are not Windows based will run PowerShell in a default console. The console is created and managed by the remoting system in use. PowerShell inherits the calling console when shelled. You would have to pre-set SSH to a width to correct this.  In a Unix environment SSH would be the shell and the Posix/Unix environment would manage it. In Windows this would only work if the designers of the Window SSH service have designed it in.

When we launch PowerShell from a shortcut PowerShell creates  console based on the defaults set in the shortcut.  You can only change these by editing the shortcut.  If we start a CMD or other console then launch PowerShell the launching console will control the PowerShell console settings.

SSH is a poor match for PowerShell/Windows but can allow access from Unix systems.  WinRM is designed to cooperate with Windows/PowerShell.  WinRM now runs on most Unix systems.

Width is also managed by the output method.  With Format-* commands the output can be controlled in the command.

SSH also has options to declare terminal width which is set to 80 by default.  I suggest setting SSH to a wider setting when you start the session.  How this is done is specific to the version of SSH you are using. 

You can't set a zero value by the looks of things, the max you could set would be

[console]::bufferwidth = 32766

• Marked as answer by Elaine JingMicrosoft contingent staff, Moderator 5 hours 26 minutes ago

You can't set a zero value by the looks of things, the max you could set would be

[console]::bufferwidth = 32766

• Marked as answer by Elaine JingMicrosoft contingent staff, Moderator 5 hours 36 minutes ago

You can't set a zero value by the looks of things, the max you could set would be

[console]::bufferwidth = 32766

• Marked as answer by Elaine JingMicrosoft contingent staff, Moderator Tuesday, August 04, 2015 1:34 AM

Strange it works fine for me - 

PS H:\> [console]::bufferwidth = 32766
PS H:\> [console]::bufferwidth
32766

Does the error occur only when running your command line or does it happen even if you just open a powershell console.

Also, where is your output being directed, just to the console or are you redirecting it somewhere else?

• Edited by Braham20 Thursday, July 30, 2015 8:35 AM

Thanks for the reply.

This gives some useful insight, but does not answer the question (even though the thread was marked as answered...).

The sshd process (or rather the childs it spawns) has ways to query the caller for terminal size, I dont know the details. What is needed is a way to pass this on to "powershell". Clearly that is a broader topic, because if that cmd is run from things like cmd.exe it runs in similar environment. But perhaps that powershell.exe has ways to recognize that it was started from a GUI which causes it to run itself in a window.

I will see if cygwin provides a way to fake the GUI environment, or at least provide the terminal settings to the callee.

this ha nothing to do with PowerShell.  You must consult the vendor of the software you are using.  PowerShell just inherits the console that is created for it.

Sorry.  It is a Windows technical issue.  No user serviceable components inside.