Add a -DisplayHint parameter to Measure-Object for disk-space representations that are easy to grasp

Follow-up from https://github.com/PowerShell/PowerShell/issues/13423#issuecomment-681153364:

Summary of the new feature/enhancement

To easily grasp the size of a directory, it would be helpful if instead of:

PS> Get-ChildItem -File |  Measure-Object -Sum  Length
...
Sum: 19241959
...

it would be nice to get an auto-scaled value that is expressed as a multiple of KB, MB, GB:

PS> Get-ChildItem -File |  Measure-Object -Sum  Length
...
Sum: 18.35MB
....

Additionally, such scaling should be available on demand. Therefore:

Introduce a new -DisplayHint parameter - analogous to Get-Date’s - as an enumeration value that instructs the formatting system to use specific formatting, as follows:

... | Measure-Object -DisplayHint { None | KB | MB | GB | AutoBytes }

• The parameter would affect the output formatting of the following properties of GenericMeasureInfo / GenericObjectMeasureInfo output type (it wouldn’t apply to the TextMeasureInfo output type selected with any one of the -Line, -Word or -Character parameters):

  • Average, Sum, Maximum, Minimum

• None would be the default, except if the first input object is of type (derived from) System.IO.FileSystemInfo and the -Property value is Length, in which case AutoBytes is implied.

Meaning of the enumeration values:

• None yields the current behavior.

• KB, MB, GB divide the numbers by the implied binary multiplier and represent the result with 2 decimal places, including the multiplier suffix:

  • E.g., with KB, value 1234 would be represented as 1.21KB, the result of '{0:N2}' -f (1234 / 1kb).

• AutoBytes auto-select the highest among the binary KB, MB, GB multipliers that makes the scaled value greater than or equal to 1, with values below the KB threshold getting suffixed with B.

  • E.g., 1100200 would be represented as 1.05MB, the result of '{0:N2}' -f (1100200 / 1mb), because MB is the highest multiplier that still yields a scaled value greater than 1.

Proposed technical implementation details (optional)

• Make Measure-Object attach an instance DisplayHint ETS member to its GenericMeasureInfo / GenericObjectMeasureInfo (as needed).

• Add formatting definitions for GenericMeasureInfo and GenericObjectMeasureInfo that acts on the DisplayHint instance member.

[mklement0]

We either use a default or explicitly specify a preference.

The proposal suggests a - what I consider sensible - default (auto-selection of an appropriate multiplier, depending on the size of the number for FileSystemInfo input with property Length), supplemented with the ability to override with a fixed multiplier - or none at all - via -DisplayHint.

It makes no sense to put a preference in the cmdlet itself

It absolutely makes sense, because in the case of FileSystemInfo and Length we know that bytes are being measured and presenting the output in those terms is the most useful to the human observer.

we should use Format-Table -View <CustomView>. The problem is that it is too time consuming and has many limitations.

Indeed: Which do you think is preferable?

Get-ChildItem -File | Measure-Object -Sum Length (with -DisplayHint AutoBytes implied) vs. Get-ChildItem -File | Measure-Object -Sum Length | Format-Table -View AutoBytes

---

As stated, Measure-Object is an unusual cmdlet, because of its open-ended input - that, and only that, is the reason why the -DisplayHint solution is appropriate.

As far as PSMore, this could overcome some of these limitations.

Please spell such a PSMore-based solution out explicitly for the case at hand.

[iSazonov]

Input objects know nothing about user preferences. I may want the output in terabytes, you in gigabytes. We either use a default or explicitly specify a preference. It makes no sense to put a preference in the cmdlet itself, since there are an infinite number of options. In terms of the existing formatting system, we should use Format-Table -View <CustomView>. The problem is that it is too time consuming and has many limitations. As far as PSMore, this could overcome some of these limitations. One key PSMOre feature is that users can modify defaults on the fly and attach formatting to objects.