How to Check If Find Command Didn't Find Anything

How to check if find command didn't find anything?

Count the number of lines output and store it in a variable, then test it:

lines=$(find ... | wc -l)
if [ $lines -eq 0 ]; then
...
fi

How to tell if the output of the find command is empty?

When you say you want it to return a particular number, are you referring to the exit status? If so:

[[ -z `find /this/is/a/path/ -name core.*` ]]

And since you only care about a yes/no response, you may want to change your find to this:

[[ -z `find /this/is/a/path/ -name core.* -print -quit` ]]

which will stop after the first core file found. Without that, if the root directory is large, the find could take a while.

How to display true if find is not empty

A few issues:

1. Use var= or read var when defining a variable, but $var when using it.

2. There is no reason to keep searching after finding a file, so do something like below, where find will -quit after finding a single file and return it as a result of the -print

   #!/bin/bash
   echo ' [Enter] a file name '    
   read findFile
   if [[ -f $(find "$HOME" -type f -name "$findFile" -print -quit) ]]; then
       echo 'yes'
   else
       echo 'no'
   fi
   

   Note that the option -quit will work on GNU and FreeBSD operating systems (which means this will work in most cases), but for example, you will need to change it to -exit on NetBSD.
   You can see this answer from Unix/Linux StackExchange for details on this option.

Also note, per Adaephon's comment, that although the / is not needed in front of $HOME, it's not wrong and the files will still be found .

find command in bash script resulting in No such file or directory error only for directories?

You don't need to escape DOT in shell glob as this is not regex. So use .AppleDouble instead of \.AppleDouble:

find $DIRTY_DIR -name .AppleDouble -exec rm -rf '{}' \;

PS: I don't see anywhere $COUNTER being incremented in your script.

bash find command with path as requirement

This will work.

find /bin/* -type f -name "*m*" -exec basename {} \;

It is equivalent to going to /bin folder and executing

find -type f -name "*m*" -exec basename {} \;

find command in bash script resulting in No such file or directory error only for directories?

You don't need to escape DOT in shell glob as this is not regex. So use .AppleDouble instead of \.AppleDouble:

find $DIRTY_DIR -name .AppleDouble -exec rm -rf '{}' \;

PS: I don't see anywhere $COUNTER being incremented in your script.

Output of find command in shell script

Written like that, the ls command is run with one file at a time in whatever order find happens to come across the names, so there won't be any meaningful time ordering.

If you have a version of find that supports the POSIX 2008 + notation, then you can use:

find . -type f -exec ls -t {} +

and this will have ls list each group of files in time order, but if the command is run more than once (lots of files), then each batch will be ordered, but the groups may well be such that file 453 was created after file 2912 in the order presented.

If you need them sorted regardless of the number of files, then you probably need to use stat command to print the file name and modification time as a number, and then sort numerically, and finally strip the number off.

On Mac OS X, you might use:

find . -type f -exec stat -f '%Dm %N' {} + | sort -n | awk '{print $2}'

(The %Dm prints the modification time as a decimal number; the %N prints the file name.)

However, if you're on Linux, you'll need to check the manual page for Linux stat since it is different. If you're on other systems, the stat command may or may not be available; it is not standardized by POSIX.

Bash - Excluding subdirectories using the find command

Following my previous comment, this works on my Debian :

find . -path ./ignored_directory -prune -o -name fileName.txt -print

or

find /path/to/folder -path "*/ignored_directory" -prune -o -name fileName.txt -print

or

find /path/to/folder -name fileName.txt -not -path "*/ignored_directory/*"

The differences are nicely debated here

---

Related Topics