[hurin]

I'm not familiar with PowerShell, but wouldn't following through with this principle mean that the default program has to give maximally verbose output to the piped formatter, since the formatter can only filter rather than extend the original command.

I imagine to achieve the default functionality your command must be significantly more verbose, if this philosophy is followed through 100%, or you have a lot of per-configured default formatters (and you have to remember what to pipe to which). Maybe I'm misunderstanding this, it's very neat in principle though.

[useerup]

PowerShell cmdlets return (active) objects in the same process space as the hosting process (usually the shell). As such they can expose expensive-to-compute properties as late-evaluated properties that are only evaluated if and when they are invoked later.

Take for instance Get-Process:

    $p = ps powershell

(ps is an alias for Get-Process). Now $p is the process information onject about the PowerShell process itself.

Type

    $p

And PowerShell will respond with

    Handles  NPM(K)    PM(K)      WS(K) VM(M)   CPU(s)     Id ProcessName
    -------  ------    -----      ----- -----   ------     -- -----------
        359      24    57096      61972   611     2,20   9608 powershell

If you request the content of $p at some later point in time, you will notice how the CPU has increased, for instance. The point is that a lot of the properties are computed when read, and hence do not incur overhead in the pipeline.

[AndrewDucker]

PowerShell returns objects, not strings. Which means they can have as much information as you like without being overly verbose :-)

[hurin]

> PowerShell returns objects, not strings. Which means they can have as much information as you like without being overly verbose :-)

How does the user know exactly which output he is going to get? The formatting program cannot know anything about default expected output - so it either must be specified explicitly, or objects must distinguish between default_for_formatter_to_output fields and more_verbose_hidden_fields - I'm really not a fan of the amount of man <command_name> using Unix involves, - but is the alternative really much better?

[sudioStudio64]

There are some sane defaults in the PS case along with heuristics that try to map arguments between pipe-out and pipe-in cmdlets. The parsing/serialization and formatting are done by the environment, not by an individual program.

It works pretty well. In the end there is also some convention that helps it work more consistently.

In practice, it is kind of cool to be able to construct new objects as the pipeline progresses so that can customize that behavior. I've found that with some aliases for default commands it can be reasonably succinct as well.

[AndrewDucker]

Each object specifies how to format itself by default.

So ls, by default, gives Mode,LastWriteTime,Length,and Name.

But if I check all of the properties I get PSPath, PSParentPath, PSChildName, PSDrive, PSProvider, PSIsContainer, BaseName, Mode, Name, Parent, Exists, Root, FullName, Extension, CreationTime, CreationTimeUtc, LastAccessTime, LastAccessTimeUtc, LastWriteTime, LastWriteTimeUtc, Attributes

[lake99]

Your comment is breaking the formatting of the entire page.

[AndrewDucker]

Fixed, thanks!

Didn't realise it wouldn't line-break!

[wz1000]

AFAIK PowerShell pipes stream objects, not text. I've never used it though.