Powershell: Cannot display two or more variables successively when "Select-Object" used

Created on 28 May 2020  路  9Comments  路  Source: PowerShell/PowerShell

Steps to reproduce

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

Expected behavior

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

Actual behavior

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






Environment data

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

Area-Cmdlets-Utility Issue-Question

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.

All 9 comments

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:

7839 (#4552 is in part about the same problem)

Open:

7871, which proposes issuing a warning if properties are "lost".

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:

  1. Getting the formatter to maybe start a new format scheme maybe continue the previous one would be a decent chunk of effort in a already complicated system.
  2. That would require checking the properties of every single item instead of just the first of each type. For the folks already making sure the objects they emit have the same properties this would be a huge performance hit.

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.

Was this page helpful?
0 / 5 - 0 ratings