5

There seem to be a lot of entries about how to use du to recursively find the largest dir and files at the same time, but none on how to only recursively find the largest files in a set of directories.

Basically, I am looking for a command to find the largest .mp3 files in my music library, not the directory containing the most amount of data.

I'm using bash on an OSX 10.8 system.

Improve this question
2

4 Answers 4

Reset to default
7

This should do it (with GNU find and sort):

find . -type f -iname '*.mp3' -printf "%b %p\0" | sort -zn | tr \\0 \\n

If you don't want the file size to be printed, only the file names:

find . -type f -iname '*.mp3' -printf "%b %p\0" | sort -zn | awk -v RS=\\0 '{ gsub("^[0-9]+ ", "") ; print }'
Improve this answer
1
  • Based on the number of upvotes, this answer seems credible, but the version of Find installed with OSX doesn't seem to support the -printf option. Apologies for not mentioning my system environment.
    – nipponese
    Nov 14, 2012 at 15:06
6

I would use :

du -a Music/ | grep "\.mp3$" | sort -n | tail -n1

provided Music is your directory

Improve this answer
7
  • 1
    This will break if there are newlines in the filenames.
    – Chris Down
    Nov 13, 2012 at 16:25
  • I didn't test this specific case, but you are probably right. This will also fail if the files do not have the mp3 extension.
    – Vincent Nivoliers
    Nov 13, 2012 at 16:27
  • Newlines in filenames are so unusual that almost always it isn't worth the effort to consider the case and program against it.
    – angus
    Nov 13, 2012 at 19:30
  • @ChrisDown I wouldn't voice an unsubstantiated opinion followed by a derogatory quip on a technical forum like this, like you just did, but to each it's own :). Anyway, if the count of filenames with newlines from all the filesystems of everybody who wrote on this page is greater than 0, then maybe you would have a point (but a small one).
    – angus
    Nov 14, 2012 at 11:32
  • 1
    @angus, the no need to be robust in this corner case as it's unlikely to occur approach is a very common source of security holes. Even though it probably doesn't matter in this very case, on a site like SE that is meant to be a reference, I'd agree with ChrisDown to try and do the right thing, and to point out the limitations when we don't go as far.
    – Stéphane Chazelas
    Nov 14, 2012 at 15:21
2

With zsh:

ls -ld -- **/*.mp3(.DOL[1,5])

Will list the 5 biggest regular files (in terms of file size, not disk usage which is not necessarily the same). With GNU ls, add the -U so that they appear in decreasing size order.

For disk usage, that would have to be:

zmodload zsh/stat
zdu() zstat -A REPLY +block -- $REPLY
du -- **/*.mp3(.nDO+zdu[1,5])

Of course, you can adapt that to other metrics associated with the file, like the duration of the MP3 in seconds:

mp3_duration() REPLY=$(exiftool -p '$Duration#' - < $REPLY)
print -rl -- **/*.mp3(.nDO+mp3_duration[1,5])
Improve this answer
1

My initial assumption was wrong, there was an existing answer to this question, detailed here:

find . -type f -print0 | xargs -0 du -s | sort -n | tail -10 | cut -f2 | xargs -I{} du -sh {}

Still gave you guys the points though.

Improve this answer
3
  • It's less efficient and less reliable (wouldn't work for filenames with newline or tab characters) than most of the answers you've been given here though
    – Stéphane Chazelas
    Nov 14, 2012 at 15:14
  • @StephaneChazelas I don't have any way to validate your opinion, but I'll assume you're right. However, this solution is the only one that would work for my environment, and still flexible enough to adjust the amount of returned results.
    – nipponese
    Nov 14, 2012 at 18:16
  • @StephaneChazelas I take it back, Vincent Nivoliers's also nailed it.
    – nipponese
    Nov 14, 2012 at 18:20

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.