Commands using find

shorter version. I believe find is faster than ls as well.

When I do a major change in my entities, I want to find a way to find all my Entities names and create the commande for me.

So instead of doing ls src/Your/OwnBundle... and then do it manually, this helps a lot.

The listing will be nice separated with dashes in chunks of identical files.

Output format:

Size Inode Mode Count_of_identical_files UID GID Date Time Path/Filename

the

In this example, the command will recursively find files (-type f) under /some/path, where the path ends in .mp3, case insensitive (-iregex).

It will then output a single line of output (-print0), with results terminated by a the null character (octal 000). Suitable for piping to xargs -0. This type of output avoids issues with garbage in paths, like unclosed quotes.

The tr command then strips away everything but the null chars, finally piping to wc -c, to get a character count.

I have found this very useful, to verify one is getting the right number of before you actually process the results through xargs or similar. Yes, one can issue the find without the -print0 and use wc -l, however if you want to be 1000% sure your find command is giving you the expected number of results, this is a simple way to check.

The approach can be made in to a function and then included in .bashrc or similar. e.g.

In this form it provides a versatile character counter of text streams :)

Search for files and list the 20 largest.

gives us a list of file, recursively, starting from here (.)

separate the names of files with NULL characters, so we're not confused by spaces

then xargs run the du command to find their size (in human-readable form -- 64M not 64123456)

use sort to arrange the list in size order. sort -h knows that 1M is bigger than 9K

finally only select the top twenty out of the list

from my bashrc ;)

This command find which of your zip (or jar) files (when you have lots of them) contains a file you're searching for. It's useful when you have a lot of zip (or jar) files and need to know in which of them the file is archived.

It's most common with .jar files when you have to know which of the .jar files contains the java class you need.

To find in jar files, you must change "zip" to "jar" in the "find" command. The [internal file name] must be changed to the file name you're searching that is archived into one of the zip/jar files.

Before run this command you must step into the directory that contains the zip or jar files.

This command finds all files in a folder recursively and sets owner and group to read and write. Leaves all dirs intact. This command does takes care of file names with spaces as well.

Helps to fix permissions when a user clobbers them in their home directory or elsewhere. Does not rely on file extension, but uses the `file` command for context.

Improvement on Coderjoe's Solution. Gets rid of grep and cut (and implements them in awk) and specifies some different mplayer options that speed things up a bit.

You must spezify /where folder and / folder

If you have another camera you must experiment with Exif data (after -g and after grep) and mask of your photo files IMG_????.JPG

I have do it on Knoppix 6.7.0

You must have installed exiv2.

Remove all the hidden CVS merge helper files that I keep seeing in my IntellIj project

This command removes *.lock or files from a folder.

This can be used to delete or archive old mails. In fact, for archiving its a bit different, you need to archive mails with any tools (e.g archivemail), and then deleting (if you want!).

Here we use -path ".*/cur/*" to avoid files limit in bash globbing and to search in any inbox (e.g .mymail .spam .whatever).

! -newermt "1 week ago" can be read: All files which is older than "1 week ago", adapt it in consequence.

This let me find some a set of modifications that were made to a rather large tree of files, where the file-names themselves were not unique (actually: insanely redundant and useless. "1.dat 2.dat ..."). Pruning down to last-branch brough things back to the "project-name" scope, and it's then easy to see which branches of the tree have recently changed, or any other similar search.

Ideally, it should sort the directories by the mtime of the most recent *file* *inside* the directory, but that's probably outside the scope of a (sane...) command line.