Take the 2-minute tour ×
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems.. It's 100% free, no registration required.

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.

share|improve this question
2  
see also Linux utility for finding the largest files/directories on SU –  warren Nov 13 '12 at 16:30
    
@warren This is what I was looking for, thanks. I answered the question with this link. –  nipponese Nov 14 '12 at 15:03

4 Answers 4

up vote 5 down vote accepted

I would use :

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

provided Music is your directory

share|improve this answer
    
This will break if there are newlines in the filenames. –  Chris Down Nov 13 '12 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 '12 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 '12 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 '12 at 11:32
    
@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 '12 at 15:21

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 }'
share|improve this answer
    
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 '12 at 15:06

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])
share|improve this answer

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.

share|improve this answer
    
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 '12 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 '12 at 18:16
    
@StephaneChazelas I take it back, Vincent Nivoliers's also nailed it. –  nipponese Nov 14 '12 at 18:20

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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