Okay what I need to do is make a list with full path names e.g. /home/t/file.mp3 of all *.mp3 files in all sub-directories of (for simplicity sake) my working directory...


I have gotten some luck with this:

But for some reason it list ALL files in in the search and doesn't filter anything....

I have also tried many additions to the above like

Any help is appreciated!!! Thanks.

Assuming you use bash:

`pwd` is needlessly complicated, . can be used to represent the current working directory.

>> appends to a file or creates it if it doesn't exist.
> empties the file if it exists then writes to it, or creates it if it doesn't exist.

That one should work, as long as you correctly quote the pattern, like you did in that example above. Also, there's no need to use pwd, just use the dot to mean "the current working dir".

Note that you are using >>, so, if you run this multiple times the contents will append... Maybe that's the problem. Maybe you ran another find command with a bigger output before that one that you posted. If that's the case, either make sure that the list.txt files doesn't exist, or use a single > to overwrite it.

okay thanks for clearing up the >> vs > and I'll try again

Off the top of my head, i think something like:
grep -i ".mp3" || ls */*

should do the trick!

Debian Kernel

Sorry if this is a double post but I want to show what worked perfectly for those with similar problems...

now can simply use:

for my linux media player!!!

I'm pretty sure 'reclusively' is not a word unless you're talking about Herman the Hermit.

I'm trying to think of a polite way of pointing out that command doesn't even make sense let alone do what the OP wants but all I can up with is this...

Of course there is no requirement that MP3 files have a .mp3 file "extension" since a the name of a Linux file does not determine the type of the file. That's done by the "Magic Number" inside the file itself.

I think that you probably want something like find . -print0 | xargs -r0 file | grep MPEG | cut -f1 -d:, although that command doesn't check that Type is III, so it will list all your MPEG files, not just the MP3 ones.

Here's a sample output with the level III test included:

That command will do the following:

1. Open an input buffer, which you can feed via stdin (using the keyboard). That what grep does when it's not fed via a file on command line, or via a pipe (probably what the poster thought it would do, if it wasn't because the pipe is not ||, but a single |, and the order of the members of the should-be-pipe are reversed as well).
2. Once you press enter, the console keeps waiting for your input
3. You write, and press control+d when you are done
4. Now, if you wrote "mp3" somewhere on your input, nothing will happen, if you did not, then ls will be run.

As you see, completely absurd for the purpose of this thread.

He probably meant:

It's much less versatile than find so I wouldn't bother with that either way.

Because of that, we can expect more accuracy and less fuzziness if we just assume that mp3 files will have [mM][pP]3 extension, which is right 99.9% of the cases. Not to speak about the processing time of your way on a big collection compared to a simple file name check with find...

uhh guys this topic is solved I don't understand why you want a better solution then what I used....

Well, not more accuracy, because you will miss some MP3 files, and include any file with mp3 anywhere in the name. (You probably want your regular expression to be grep -i '\.mp3$' since an unescaped . matches any character, and, without the $, it will match anywhere in the name string.)

And, as I demonstrated in my example, you would miss any MP3 files without the ".mp3" somewhere in their name. That example also demonstrates how to restrict your output to type III MP files.

So your"preferred" solution is both less accurate and more "fuzzy" than mine. I will, however, concede that my solution does add one extra processing step, so you do pay a small price for accuracy and precision.

As we like to point out, Linux is about choice, so you can choose whatever method suits you. My inclination is to make a few assumptions as I can about things, and to test any assumptions that I can, but you may feel differently.

No, you want "find", which is what I suggested on first place, and also "the right tool" for this case. That way there's no fuzziness at all (-name "*.[mM][pP]3" is the closest that you can get at all without analyzing file contents). I agree that ls's and grep's are not a smart solution for this concrete case.

That's the only universal truth