> On Jan 29, 2020, at 10:26 AM, Jason McIntyre <[email protected]> wrote: > > On Wed, Jan 29, 2020 at 11:12:56AM -0500, David Goerger wrote: >> Monday, 20200127 18:29-0500, Daniel Jakots wrote: >>> Can't you achieve what you want with `du -sh * | sort -h`? du(1)'s >>> -h options will automatically select the best suffix and sort(1)'s >>> -h will sort first using the suffix then the numerical value. >> >> Thanks! I didn't know about "sort -h". That indeed does what I want, >> and is a bit more readable (e.g. 8G instead of the quick mental math >> in evaluating 8192M). Like Todd said, old habits die hard. And at >> least in my case, I'm pleasantly surprised any time a tool features >> smart extensions and I don't have to manipulate arrays of raw >> integers. :) >> >> Actually, I think you've convinced me that using "sort -h" is better. >> In particular, I like that it future-proofs us up to and including >> yottabytes. What about something like this, to highlight this common >> use case? >> >> --- >> Index: du.1 >> =================================================================== >> RCS file: /cvs/src/usr.bin/du/du.1,v >> retrieving revision 1.35 >> diff -u -p -r1.35 du.1 >> --- du.1 2 Sep 2019 21:18:41 -0000 1.35 >> +++ du.1 29 Jan 2020 16:02:45 -0000 >> @@ -147,6 +147,16 @@ option is specified. >> .El >> .Sh EXIT STATUS >> .Ex -std du >> +.Sh EXAMPLES >> +To sort human-readable output by size, one might use the human-readable >> +extension to >> +.Xr sort 1 , >> +for example: >> +.Pp >> +.Dl du -sh * | sort -h >> +.Pp >> +This is useful to quickly identify large files and folders consuming >> +disk space. >> .Sh SEE ALSO >> .Xr df 1 , >> .Xr fts_open 3 , >> > > [...] > > - i guess if you have a lot of stuff it makes sense to have the biggest > files displayed at the end of the list. but generally wouldn;t you > want your biggest files listed first? we could add -r to sort.
Our sort(1) has an '-r' flag for "reverse".
