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 ,
>
hi.
i don;t think it would be such a bad thing for du to have an example or
two, so i'm ok with this.
couple of points:
- the description is way too wordy. it is definitely better to try and
avoid this structure for simple cases:
1st part of description:
$ blah
2nd part of description.
so sth like:
Display a summary of files and folders in the current directory,
sorted by size:
$ blah
- 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.
jmc
