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
Enable formatting of different object types in same pipeline #4552
Comments
Yes, the 300 ms wait was added to improve formatting of column widths, however, this issues seems to be an unintended side-effect. |
I'm glad to hear it. Unfortunately I just realized that the behavior described in this issue is as designed and not related to the 300 ms. wait - see below (I've also removed my original explanation above). So, unless I'm wrong again, I suggest:
(Adapted from https://stackoverflow.com/a/45705068/45375.) All output produced by a given script - even across separate commands - is sent to the same pipeline. While you can send any mix of data types to a pipeline, its default display formatting is optimized for objects of the same type, as that is the more typical case. The following is in part based on experimentation - do tell me if I got something wrong. In the absence of explicit formatting commands ( However, it is the first object sent to the pipeline that determines the display format for all objects:
Again, note that even "disappearing" objects are just a display problem: the objects are there, and sending them to another command for further processing works just fine. Why using an explicit formatting command helps: By explicitly piping to a An alternative is to use a generic workaround: if you pipe to
It is important to note that these workarounds are suitable only for display purposes, because the original objects are lost in the process:
|
Thanks @mklement0; agree that this behaviour makes sense. However, it's a definite gotcha for the uninitiated / unwary. Many people will want to avoid putting formatting commands in their functions as that then limits their reuse. Whilst they could avoid the issue by returning the different result types as different properties on a custom object (i.e. thus keeping them clearly distinct in the pipeline, whilst allowing them to be formatted as required down the line), this kind of thing will catch out a lot of people who've not hit it previously. It would be helpful if the implicit
However, some solution along those lines would be helpful... Though I suspect it would be an enhancement rather than a bug... |
I agree that this trips up people and open to suggestions on how to enhance this, however, it should probably be a RFC |
Just some quick food for thought on how to address this: Building on @JohnLBevan's suggestions, here's a quick-and-dirty prototype for a potential new Function Format-Grouped {
$Input | Group-Object {
if ($_ -is [System.Management.Automation.PsCustomObject])
{ [string] $_.psobject.properties.Name }
else
{ $_.GetType().FullName }
} |
ForEach-Object { $_.Group | Out-String }
} It groups the pipeline objects by type and outputs each group of objects of the same type with that type's default formatting; in the case of custom objects, they're grouped by shared array of property names. A much simpler, streaming function that simply formats each input object individually, which notably means that table-formatted objects each get a table header, even if they occur in blocks. Filter Format-Each { $_ | Out-String } Example with regular types: > & { Get-ChildItem -File /; Get-Process | Select-Object -First 2 } | Format-Grouped
Directory: /
Mode LastWriteTime Length Name
---- ------------- ------ ----
--r--- 7/30/16 10:00 PM 313 installer.failurerequests
--r--- 8/10/17 3:53 PM 146 lastlogout_hook.txt
NPM(K) PM(M) WS(M) CPU(s) Id SI ProcessName
------ ----- ----- ------ -- -- -----------
0 0.00 0.00 0.00 0 942
0 0.00 0.00 0.00 1 1
Example with custom objects: > & { [pscustomobject] @{ one = 1; two = 2 }; [pscustomobject] @{ four = 4} } | Format-Grouped
one two
--- ---
1 2
four
----
4
|
@SteveL-MSFT is it best that I raise a new issue on here to track this as an RFC, or could we retag this existing issue for that purpose? |
@JohnLBevan We continue in #4594 |
Didn't see @iSazonov reply which sounds good, re-resolving |
Perhaps the solution to the asynchronous problem will implicitly give us the behavior that @JohnLBevan suggests here, but we should keep in mind that they are really two separate issues:
I've folded a description of the latter into #4594, at least for now. |
When running some commands in sequence, if no
Format-
command is explicitly stated, output may not show. I believe this occurs when one command formats data as a table, and the subsequent command erroneously attempts to put its data into this same table.Issue first observed by LukeZeimet at: https://stackoverflow.com/questions/45637800/powershell-if-condition/45638510?noredirect=1#comment78237014_45638510
Steps to reproduce
Running the following only shows the output of Test-Connection, not of
Get-WmiObject
, despiteGet-WmiObject
giving results / working when run alone:Expected behavior
Output:
Actual behavior
Environment data
The text was updated successfully, but these errors were encountered: