You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Format-Table -Wrap produces strange output for a mix of long lines and lines containing tabs #6313
There is an extra line after the first and last element (in fact there is an extra line after every row except the one with the wrapping value)
The row that has the long value is wrapped strangely.
Environment data
>$PSVersionTable
Name Value
---------
PSVersion 6.0.1
PSEdition Core
GitCommitId v6.0.1
OS Microsoft Windows 6.1.7601 S
Platform Win32NT
PSCompatibleVersions {1.0,2.0,3.0,4.0...}
PSRemotingProtocolVersion 2.3
SerializationVersion 1.1.0.1
WSManStackVersion 3.0
and
Name Value
---------
PSVersion 6.0.1
PSEdition Core
GitCommitId v6.0.1
OS Linux 4.15.6-1-default #1 SMP PREEMPT Sun Feb 25 18:51:57 UTC 2018 (06f0b06)
Platform Unix
PSCompatibleVersions {1.0,2.0,3.0,4.0...}
PSRemotingProtocolVersion 2.3
SerializationVersion 1.1.0.1
WSManStackVersion 3.0
Removing the tab character from the first object's property (or even replacing it with 8 spaces) fixes the extra line between the rows but does not fix the strange wrapping of the long row.
Shortening the long row so that it does not need to wrap also fixes the extra line between the rows.
There is now also an empty line between the two parts of the wrapping second row. This line does not go away if I replace the tab in the first row with spaces, but does go away if I replace the tab in the second row with spaces.
With current master (GitCommitId: v6.0.1-230-g20b0e9cc61af122f95225568f54e290793fa78c8) on Windows 7, it doesn't have the empty lines for both test cases, but does still have the strange wrapping for the first test case.
The way -Wrap works is that it tries not to split a word. So in the second case above (w/ latest master), the wrap inserts a newline after the first 'd' * 100 since it fits, but puts the second one on a new line rather than split it. In the first case, the tab character's display size isn't taken into account, so it treats it as size 1. 'd' * 200 is wider than the width of the console, so it has to split it in half, but due to the wrong total length calculation of the tab, it inserts the newline in the wrong place.
Not sure how to fix this for all cases. On macOS, the default tab stop is 8, so a`tb would show "a<seven spaces>b". However you can use tabs -4 to change the tab stop to 4 or even set different sizes for tab stop 1, 2, ... so we can't make assumptions about the tab stops.
I suppose one option is when using format-table -wrap, we convert the tabs to four spaces.
I guess there is many kinds of terminals with exclusive settings - easiest way for PowerShell is to ignore a terminal (tab) settings and use its own settings. (We could have PSTabExpansion.) Although this may not work well when the window size is changed.
This issue has not had any activity in 6 months, if this is a bug please try to reproduce on the latest version of PowerShell and reopen a new issue and reference this issue if this is still a blocker for you.
microsoft-github-policy-service commented on Nov 16, 2023
This issue has not had any activity in 6 months, if this is a bug please try to reproduce on the latest version of PowerShell and reopen a new issue and reference this issue if this is still a blocker for you.
This issue has not had any activity in 6 months, if this is a bug please try to reproduce on the latest version of PowerShell and reopen a new issue and reference this issue if this is still a blocker for you.
microsoft-github-policy-service commented on Nov 23, 2023
Activity
Arnavion commentedon Mar 5, 2018
Anotehr bit of strange behavior for
PS 5.0:
PS Core:
There is now also an empty line between the two parts of the wrapping second row. This line does not go away if I replace the tab in the first row with spaces, but does go away if I replace the tab in the second row with spaces.
iSazonov commentedon Mar 6, 2018
Arnav Singh (@Arnavion) Thanks for you report. Could you please repo with later daily build?
Arnavion commentedon Mar 6, 2018
With current master (
GitCommitId: v6.0.1-230-g20b0e9cc61af122f95225568f54e290793fa78c8) on Windows 7, it doesn't have the empty lines for both test cases, but does still have the strange wrapping for the first test case.iSazonov commentedon Mar 6, 2018
Arnav Singh (@Arnavion) Thanks for the repo.
/cc Steve Lee (@SteveL-MSFT) Could you please comment the Issue?
SteveL-MSFT commentedon Mar 6, 2018
Looks like a bug in the wrapping logic. I'll look into this.
SteveL-MSFT commentedon Mar 9, 2018
The way
-Wrapworks is that it tries not to split a word. So in the second case above (w/ latest master), the wrap inserts a newline after the first'd' * 100since it fits, but puts the second one on a new line rather than split it. In the first case, the tab character's display size isn't taken into account, so it treats it as size 1.'d' * 200is wider than the width of the console, so it has to split it in half, but due to the wrong total length calculation of the tab, it inserts the newline in the wrong place.Not sure how to fix this for all cases. On macOS, the default tab stop is 8, so
a`tbwould show "a<seven spaces>b". However you can usetabs -4to change the tab stop to 4 or even set different sizes for tab stop 1, 2, ... so we can't make assumptions about the tab stops.I suppose one option is when using
format-table -wrap, we convert the tabs to four spaces.iSazonov commentedon Mar 12, 2018
I guess there is many kinds of terminals with exclusive settings - easiest way for PowerShell is to ignore a terminal (tab) settings and use its own settings. (We could have
PSTabExpansion.) Although this may not work well when the window size is changed./cc Michael Klement (@mklement0)
SteveL-MSFT commentedon Mar 12, 2018
There are already some places in the PowerShell code base that replaces tabs with four spaces, although it's not consistent everywhere.
microsoft-github-policy-service commentedon Nov 16, 2023
This issue has not had any activity in 6 months, if this is a bug please try to reproduce on the latest version of PowerShell and reopen a new issue and reference this issue if this is still a blocker for you.
microsoft-github-policy-service commentedon Nov 16, 2023
This issue has not had any activity in 6 months, if this is a bug please try to reproduce on the latest version of PowerShell and reopen a new issue and reference this issue if this is still a blocker for you.
microsoft-github-policy-service commentedon Nov 16, 2023
This issue has not had any activity in 6 months, if this is a bug please try to reproduce on the latest version of PowerShell and reopen a new issue and reference this issue if this is still a blocker for you.
microsoft-github-policy-service commentedon Nov 23, 2023
This issue has been marked as "No Activity" as there has been no activity for 6 months. It has been closed for housekeeping purposes.