By default, an object at the end of a pipeline will be printed to the screen in tabular format.

    (australis) ~\Desktop % Get-ItemProperty e
        Directory: C:\Users\Dustin\Desktop
    Mode                LastWriteTime         Length Name
    ----                -------------         ------ ----
    d-----        8/12/2016   9:06 AM                e

I believe types can specify which columns to display by default; if you want more info, there's always `Format-List`:

    (australis) ~\Desktop % Get-ItemProperty e | format-list
        Directory: C:\Users\Dustin\Desktop
    
    Name           : e
    CreationTime   : 8/11/2016 10:58:56 PM
    LastWriteTime  : 8/12/2016 9:06:13 AM
    LastAccessTime : 8/12/2016 9:06:13 AM
    Mode           : d-----
    LinkType       :
    Target         : {}

It's also possible to format any object via `ConvertTo-JSON`:

    (australis) ~\Desktop % Get-ItemProperty e | ConvertTo-JSON
    {
        "Name":  "e",
        "Parent":  {
                       "Name":  "Desktop",
                       "Parent":  {
                                      "Name":  "Dustin",
                                      "Parent":  "Users",
                                      "Exists":  true,
                                      "Root":  "C:\\",
                                      "FullName":  "C:\\Users\\Dustin",
                                      "Extension":  "",
  ...

> I believe types can specify which columns to display by default;

Indeed, the default view (table/list/custom) can be specified, and for the view the default properties can be specified.

Consider how 'ls' produces a sequence of FileSystemInfo objects (when run against a disk file system). The view specifies that the list be grouped by "parent".

On the terminal this gives a nice list a la:

        Directory: C:\Dell\Drivers\T7MFF\PhysX\files\Engine\v2.8.0


    Mode                LastWriteTime         Length Name
    ----                -------------         ------ ----
    -a----       12-12-2014     07:42         362232 NxCooking.dll
    -a----       12-12-2014     07:42        5520120 PhysXCore.dll


        Directory: C:\Dell\Drivers\T7MFF\PhysX\files\Engine\v2.8.1


    Mode                LastWriteTime         Length Name
    ----                -------------         ------ ----
    -a----       12-12-2014     07:42         363256 NxCooking.dll
    -a----       12-12-2014     07:42        5823736 PhysXCore.dll


        Directory: C:\Dell\Drivers\T7MFF\PhysX\files\Engine\v2.8.3


    Mode                LastWriteTime         Length Name
    ----                -------------         ------ ----
    -a----       12-12-2014     07:42         339192 PhysXCooking.dll
    -a----       12-12-2014     07:42         412408 PhysXCooking64.dll
    -a----       12-12-2014     07:42        5952248 PhysXCore64.dll

However, the underlying stream is still just a continous stream of FileSystemInfo's. It is the terminal display format definition that causes it formatting to break and write a directory heading whenever the next item has a different parent from the previous one.

You can certainly print them, but there's no guarantee you'll get all its contents by default, and there's still the problem of how to create those objects from some other output, e.g. in a file.

http://windowsitpro.com/powershell/powershell-objects-and-ou...

It could be said that, in some ways, unstructured streams are far more WYSIWYG, which can conceptually mean easier understanding and use.

Or it can mean a lot harder to understand and use. With types you get all of the metadata that you might not even have if it was plain text. In addition, every application chooses it's own serialization format. In the end, the only programs that compose well are those that work on text, not structured data (i.e. grep, awk, sed, etc...)

> You can certainly print them, but there's no guarantee you'll get all its contents by default, and there's still the problem of how to create those objects from some other output, e.g. in a file.

That's what CliXML is for. Export-CliXml writes objects to a file. Import-CliXml reads them back.

I think they're assuming the default view output is being used for Export-CliXML, when really it's serializing the object passed to it.

You can print them, but you can't serialise them in a way that can be later unserialised.

> You can print them, but you can't serialise them in a way that can be later unserialised.

Nope, that's wrong:

    Export-CliXml
    Import-CliXml

(https://technet.microsoft.com/en-us/library/hh849916.aspx)

For instance:

    PS> ps|Export-Clixml myprocesses.xml
    PS> Import-Clixml .\myprocesses.xml

    Handles  NPM(K)    PM(K)      WS(K)     CPU(s)     Id  SI ProcessName
    -------  ------    -----      -----     ------     --  -- -----------
        297      15     3856      13304              4024   0 aeagent
         88       7     1420       4808              3804   
    ...

CliXml (Command Line XML, IIRC) is a serialization format for PowerShell objects. It is the format used to transfer objects to/from remote machines when PS remoting is used.

Granted, the re-hydrated objects are not the original objects. Most method will not work after re-hydration as the object has been ripped from it's context. Think ProcessInfo (the objects returned from 'ps' (Get-Process)) - in it's original form it can be used to interact with the process, e.g. terminating it. In the rehydrated form it can be used only to inspect properties.

Speaking from experience, this is rarely a problem. CliXML works remarkably well.