Try to display 2 variable successively for example :
$Adapters = Get-NetAdapter | Select-Object Name, Status, MacAddress
$IPAddress = Get-NetIPAddress | Select-Object InterfaceAlias, IPAddress
$Adapters
$IPAddress
or :
$printers = Get-Printer | Select-Object Name, Type, DriverName
$process = Get-Process | Select-Object ProcessName, ID, Handles
$printers
$process
Must display the two variables successively, like, for the first example :
Name Status MacAddress
---- ------ ----------
Wi-Fi Disconnected XX-XX-XX-XX-XX-XX
Ethernet Up XX-XX-XX-XX-XX-XX
InterfaceAlias IPAddress
-------------- ---------
Ethernet ffff:ffff:ffff:ffff:ffff
Wi-Fi ffff:ffff:ffff:ffff:ffff
Ethernet 10.10.10.10
Wi-Fi 10.10.10.11
Displays only the first variable and some spaces below it
Name Status MacAddress
---- ------ ----------
Wi-Fi Disconnected XX-XX-XX-XX-XX-XX
Ethernet Up XX-XX-XX-XX-XX-XX
Name Value
---- -----
PSVersion 7.0.1
PSEdition Core
GitCommitId 7.0.1
OS Microsoft Windows 10.0.18363
Platform Win32NT
PSCompatibleVersions {1.0, 2.0, 3.0, 4.0鈥
PSRemotingProtocolVersion 2.3
SerializationVersion 1.1.0.1
WSManStackVersion 3.0
For information, do the same with 5.1
The only workaround I currently have is to add "Out-String" and it work, like :
$Adapters | Out-String
$IPAddress | Out-String
or second workaround: out-default
This is because Select-Object generates objects of the same type always, and the formatter doesn't handle that well if you don't have something of a different type in between them, or use Out-Default as mentioned.
To add to @vexx32's comment: the short of it is that _implicit_ Format-Table
formatting locks the display columns in based on the _first_ object's properties This Stack Overflow answer explains the problem in more detail.
This has come up previously in a number of issues:
Closed as by-design:
Open:
Cases like this and the prevalence of PSCustomObject use in PS is part of why I think that the decisions made in #7839 and #4552 are missing the point. 馃槙
Of course we want to encourage use of similar-shaped objects in a single output stream, but I think the current behaviour is simply completely unhelpful. It does little to help you diagnose what's wrong when it does happen, and it hides information that could (and imo should) still be shown to the user.
Of course we want to encourage use of similar-shaped objects in a single output stream, but I think the current behaviour is simply completely unhelpful. It does little to help you diagnose what's wrong when it does happen, and it hides information that could (and imo should) still be shown to the user.
Yeah that's true, here are the obstacles:
While I think the best practice of similar shaped objects is a good enough reason, there are also some pretty significant technical challenges.
馃
What if we implemented a sort of hashcode-style check for property/member collections that's based on each property's name? Then the display system can just check that.
What if we implemented a sort of hashcode-style check for property/member collections that's based on each property's name? Then the display system can just check that.
That's probably more or less how 2
would be implemented. You'd still need to do that once for every object. Generating a hash code for a sequence of sequences (e.g. a collection of strings) is still pretty expensive.
What if we added an explicit command FLUSH-HOST
? The formatting problem affects mainly script writers, so they would need to know when the type in the output pipeline changes, which is doable IMHO.
Most helpful comment
Cases like this and the prevalence of PSCustomObject use in PS is part of why I think that the decisions made in #7839 and #4552 are missing the point. 馃槙
Of course we want to encourage use of similar-shaped objects in a single output stream, but I think the current behaviour is simply completely unhelpful. It does little to help you diagnose what's wrong when it does happen, and it hides information that could (and imo should) still be shown to the user.