YJL: Listing largest files and directories in human-readable size with du or find

Until today, I was totally unaware of du options --all (-a), --one-file-system (-x), and --separate-dirs (-S). All I had done with it before was du -sh, occasionally, du -h --max-depth=1.

Thats all I knew about du. If Id need to list the files by the file size, then Id use find with -printf '%s %p\n' like in this thread. I had no idea you could use du for files, I always thought it was only for directories.

After read the first reply and the manpage, I now know I could just run:

du -axS | sort -h | tail

But its not perfect because we most likely would only be interested in files, not directories; unfortunately, du can not filter out directories for you. As a matter of fact, we use -a to include files at first place. Also note that -S is a crucial option, without it upper directorys size will include sizes of sub-directories sizes, not just the files reside directly under it.

Even though it includes directories, the one-liner is good enough for me, or you can have the following one if you insist to have directories excluded:

find -type f -printf '%s %p\n' |
sort --numeric-sort |
tail |
while read size path; do
  S=$((size/1024/1024))
  if ((S)); then
    echo ${S}MB $path
  else
    S=$((size/1024))
    if ((S)); then
      echo ${S}KB $path
    else
      echo ${size}B $path
    fi
  fi
done

or a simplier version since we are looking for largest files:

find -type f -printf '%s %p\n' |
sort --numeric-sort |
tail |
while read size path; do
  echo $((size/1024/1024))MB $path
done

Ive replied with multiple options and simple runtime comparison to that thread.

You always can learn a few things about using commands, and it seems to be impossible to use a Unix-like command to its full potential in my opinion. You know the knowledge of those commands have been written for very long time, only no one really RTFM. Every time I read a manpage, I always learn something I didnt know not something new, and for what Ive just learnt, they may not be the reason of why I read manpage. manpage is full of surprises.