Consider easier to read file lengths in directory listings.
Summary of the new feature / enhancement
There have over the years been multiple suggestions for "I think a directory listing should look different" , so I will apologise for adding one. I'm also aware that one can personalize the formatting XML and I have helped other people to do that. OK. I bought a new external hardisk and did a backup of my laptop (machine name Elasmo) Here's what I see
Directory: D:\WindowsImageBackup\ELASMO\Backup 2024-07-03 205724
Mode LastWriteTime Length Name
---- ------------- ------ ----
-a--- 04/07/2024 01:36 859832320 0a72971c-7f53-43a3-b802-a18b0fcb0b5f.vhdx
-a--- 04/07/2024 01:35 776 71a539b2-457c-49bf-b00a-30c9b87935e1_AdditionalFilesc3b9f3c7-5e52-4d5e-8b20-19adc95a34c7.xml
-a--- 04/07/2024 01:35 17088 71a539b2-457c-49bf-b00a-30c9b87935e1_Components.xml
-a--- 04/07/2024 01:35 6884 71a539b2-457c-49bf-b00a-30c9b87935e1_RegistryExcludes.xml
-a--- 04/07/2024 01:35 10726 71a539b2-457c-49bf-b00a-30c9b87935e1_Writer4dc3bdd4-ab48-4d07-adb0-3bee2926fd7f.xml
-a--- 04/07/2024 01:35 1488 71a539b2-457c-49bf-b00a-30c9b87935e1_Writer542da469-d3e1-473c-9f4f-7847f01fc64f.xml
-a--- 04/07/2024 01:35 1484 71a539b2-457c-49bf-b00a-30c9b87935e1_Writera6ad56c2-b509-4e6c-bb19-49d8f43532f0.xml
-a--- 04/07/2024 01:35 2940 71a539b2-457c-49bf-b00a-30c9b87935e1_Writerafbab4a2-367d-4d15-a586-71dbb18f8485.xml
-a--- 04/07/2024 01:35 6722 71a539b2-457c-49bf-b00a-30c9b87935e1_Writerbe000cbe-11fe-4426-9c58-531aa6355fc4.xml
-a--- 04/07/2024 01:35 5402 71a539b2-457c-49bf-b00a-30c9b87935e1_Writercd3f2362-8bef-46c7-9181-d62844cdc0b2.xml
-a--- 04/07/2024 01:35 7345084 71a539b2-457c-49bf-b00a-30c9b87935e1_Writere8132975-6f93-4464-a53e-1050253ae220.xml
-a--- 04/07/2024 01:36 1298450612224 a33d2db2-06cd-47f6-887a-7853ac70e49f.vhdx
-a--- 04/07/2024 01:35 1528 BackupSpecs.xml
-a--- 04/07/2024 01:36 62914560 Esp.vhdx
How big are the 3 VHDX files ?
Once a number gets beyond half a dozen digits it is really hard to judge the size at a glance. In this case 1298450612224 needs me to count the digits to see it is 1,298,450,612,224 .
The default formatting could include commas, or could change the numbers to read either 1298 GB or 1.3TB (similar to file explorer in Windows) .
Proposed technical implementation details (optional)
Change the formatting XML to either use "N0" (number separators, no decimals) as the format for the length column OR Use a script block to convert numbers above some size to TB, GB etc.
OR Use a script block to convert numbers above some size to TB, GB etc.
It would be nice to have this by default.
Better yet, some kind of helper-cmdlet for generating custom formatting. As concept:
Export-CustomFormatData -TypeName System.IO.DirectoryInfo
-TableView
-Header @{ Name = 'Mode'; Width = 8 }
....
-Header @{ Name = 'Size'; Width = 6; Expression = { <script> }; align = 'Right' }
-OutFile CustomFormat-Directory.ps1xml
I have this already when using the PowerShellHumanizer module on the gallery and gives this as output
However Yes this should be something that we get by default.
Submitted for the Cmdlet Working Group to consider
@PowerShell/wg-powershell-cmdlets reviewed this, we agreed to expose a $PSStyle.HumanReadable setting which is an object with properties indicating what types of formatted data would be humanized as booleans: Size, Datetime, Timespan and others can be added in the future as needed. Only Size would be $true by default as we expect most users would want that particularly for Get-ChildItem. Before any implementation starts, we ask that someone make the effort to write an implementation design proposal in this issue. ps1xml files would use $PSStyle to determine when to humanize.
I'll spend some time on this in the latter half of the month if no one else has grabbed it by then
I'll spend some time on this in the latter half of the month if no one else has grabbed it by then
I'll try to get it done by then - I was away on vacation when Steve's message came in and have been trying to find a couple of hours to do it since I returned.
@jhoneill It would be good to catch up and chat through this (& other things too ofc) as it's been a while since we last got chance to do so. If that sounds good I should be able to find some time between other things like Slide deck & demo prep
@jhoneill - this has been on my to get back to for a while now - if you are interested in getting this done could we link up & get this done together?
Related, is there a method already available to "humanize" bytes to kb/mb/gb intelligently? I saw a reference to Humainzer.Core in the cgmanifest and thirdparty notices but it doesn't seem to be actually used anywhere.
@JustinGrote - Yeah there's this method in the Humanizer.dll which is bundled in with all supported versions of PowerShell
[Humanizer.Bytes.ByteSize]::FromBytes((get-Item C:\tmp\PowerShell-7.5.0-win-x64.exe).Length)
gives us this output
just note about the desire to have this configurable with on/off as it's gonna have perf impact if we force it on for everyone (even if we recommend that it should be for best experience)
Thanks, I wasn't sure if there was a SMA-fronted proxy API or something I should be using. Thanks.
EDIT: Implemented for webrequest verbose/debug PR as a potentially useful example:
Adding to this, there is a feature already today where files not on disk as marked with FileAttributes.Offline and this wraps the Length property in () like so
versus this when you use a module like PowerShellHumanizer
So this would need to duplicated when we add this for a similar UX to today