8000 The length of the pipe of a text output is relative to the window size · Issue #25500 · PowerShell/PowerShell · GitHub
[go: up one dir, main page]

Skip to content

The length of the pipe of a text output is relative to the window size #25500

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
5 tasks done
fkosa opened this issue May 3, 2025 · 2 comments
Open
5 tasks done

The length of the pipe of a text output is relative to the window size #25500

fkosa opened this issue May 3, 2025 · 2 comments
Labels
Needs-Triage The issue is new and needs to be triaged by a work group.

Comments

@fkosa
Copy link
fkosa commented May 3, 2025

Prerequisites

Steps to reproduce

If I pipe the output of a script (Get-FileHash for example), the strimg is truncated at the width of the window.

It should write the whole string into the file.
The behaviour is the same if the screen is the output. It should breake (feed) the line and continue to print the string to the next line.

The bug can be reproduced in any version and in any OS.

Expected behavior

PS /Users/fkosa/Downloads> Get-FileHash ./okular-master-5944-macos-clang-arm64.dmg > okular.hash
PS /Users/fkosa/Downloads> cat ./okular.hash                                                    

Algorithm       Hash                                                                   Path
---------       ----                                                                   ----
SHA256          3BE0419CC682BA6713F68FE94A80D1BEF22856B9D9629FDA772E074F52E11A5F       /Users/fkosa/Downloads/okular-master-5944-macos-clang-arm64.dmg

PS /Users/fkosa/Downloads>

Actual behavior

PS /Users/fkosa/Downloads> Get-FileHash ./okular-master-5944-macos-clang-arm64.dmg > okular.hash
PS /Users/fkosa/Downloads> cat ./okular.hash

Algorithm       Hash                                                                   Path
---------       ----                                                                   ----
SHA256          3BE0419CC682BA6713F68FE94A80D1BEF22856B9D9629FDA772E074F52E11A5F       /Users/fkosa/Downloads/okular-master-5944-…

PS /Users/fkosa/Downloads>

Error details

Environment data

PS /Users/fkosa/Downloads> $PSVersionTable

Name                           Value
----                           -----
PSVersion                      7.5.0
PSEdition                      Core
GitCommitId                    7.5.0
OS                             Darwin 24.4.0 Darwin Kernel Version 24.4.0: Fri Apr 11 18:34:14 PDT 2025; root:xnu-11417.101.15~1…
Platform                       Unix
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0…}
PSRemotingProtocolVersion      2.3
SerializationVersion           1.1.0.1
WSManStackVersion              3.0

PS /Users/fkosa/Downloads>

Visuals

If windowed:
Image

If fullscreen:
Image

@fkosa fkosa added the Needs-Triage The issue is new and needs to be triaged by a work group. label May 3, 2025
@rhubarb-geek-nz
Copy link
rhubarb-geek-nz commented May 4, 2025

It isn't pipe text that is truncated, it is the formatting in Format-Table that is doing the truncating to align the columns.

I can see a few problems with this. With standard POSIX redirection you can determine the type of file descriptor that is used for stdout, whether it is a pipe, socket, tty or file. A program could then use COLUMNS or LINES when it identifies it as a tty. With PowerShell a given cmdlet or function has no idea what will be consuming the success pipeline.

I suspect that the Format-List/Format-Table family assume the output goes to a console. If you pipe an object that is not a string to the output then Out-String (or whatever is used) will need to choose to use one of the format cmdlets to convert the object to a suitable format for writing.

A second problem is that Format-Table constructs the table on the fly. It does not read all the input records then present the best format. It waits till either the end of the input or the first couple of records have been read. which ever comes first then sizes the columns based on what it has. All subsequent records then have the same column width.

@jhoneill
Copy link

Long ago someone decided that X > file should put the same thing in the file as appeared on the console.
The work round is to do
x | out-string -width 1000 > file

It's in the "irritating things that have been that way for so long fixing them will create problems" pile.

Actually @rhubarb-geek-nz format-table and format-list don't set the widths. We can store their output ...

Image

If I then split the panes the table objects are formatted differently

Image

and out-string "fixes" it

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Needs-Triage The issue is new and needs to be triaged by a work group.
Projects
None yet
Development

No branches or pull requests

3 participants
0