I'm trying to find the number of dirs and files in a given dir. I'm running my bash script like this:

ARCHIVE=/path/to/archive ./myScript

in my script I am doing this:

#find the number of non-empty directories in the given dir 
dirs=$(find $ARCHIVE -mindepth 1 -maxdepth 1 -not -empty -type d | wc -l)
#find the number of files in the given dir
msgs=$(find $ARCHIVE -type f | wc -l)

echo "Number of directories: $dirs"
echo "Total number of messages: $msgs"

This works great when I am running the script on a subset of the data I'm looking at, which is located in a dir at the same level as the script. However, the actual data is in someone else's directory and when I run it with the ARCHIVE variable set to that location, both values return as 0. I have a similar script that I use as well, and the find command there does not work on the second directory either. Strangely enough, I use some egrep commands and they work just fine for both.

Why can I not use find in this manner?

  • did you try running your script with bash -x so it shows you debugging information and variable expansion?
    – roadmr
    Oct 16, 2013 at 14:29
  • yes, the variable expands to the correct location, and nothing looks out of the ordinary
    – turbo
    Oct 16, 2013 at 14:34
  • I would surround $ARCHIVE with double quotes, like this: find "$ARCHIVE" -min.... Also make sure you have permission to access the other person's data.
    – ladaghini
    Oct 16, 2013 at 15:05
  • Just to clarify, your ARCHIVE variable is specifying two directories for find to look in. One is /path/to/archive, the other is ./myScript. So find will look in those two directories. Is this what you intended?
    – roadmr
    Oct 16, 2013 at 15:07
  • @ladaghini double quotes didn't change anything, and since grep works, I assume I have access? Do I need more than read access to those files?
    – turbo
    Oct 16, 2013 at 15:09

2 Answers 2


Try passing the directory you want to search as a parameter to the bash script:

#!/usr/bin/env bash

# First argument to script shall be directory in which to search

#find the number of non-empty directories in the given dir 
dirs=$(find "$ARCHIVE" -mindepth 1 -maxdepth 1 -not -empty -type d | wc -l)
#find the number of files in the given dir
msgs=$(find "$ARCHIVE" -type f | wc -l)

echo "Number of directories: $dirs"
echo "Total number of messages: $msgs"

Running the script, called dirfiles, on my home directory:

$ ./dirfiles ~
Number of directories: 27
Total number of messages: 8703

And on /usr/lib:

$ ./dirfiles /usr/lib
Number of directories: 161
Total number of messages: 9630

Furthermore, find offers three ways to resolve symbolic links:

  • -P: don't follow symbolic links
  • -L: follow symbolic links
  • -H: don't follow symbolic links except when processing command line arguments.

If you don't want to follow symlinks, but $ARCHIVE happens to be one, then perhaps -H is the way to go.

  • Still did not work, I'm almost positive this is an issue of permissions somehow. Is there a way to figure out what permissions are needed to use find? As seen in the comments of @Radu's answer, I don't see why those permissions would be insufficient to run find.
    – turbo
    Oct 16, 2013 at 15:53
  • 1
    Have you tried running, e.g., just find /your/directory -mindepth 1 -maxdepth 1 -not -empty -type d and verifying the output matches the numbers given by the script? Also, you need execute permission on a directory to search it.
    – ladaghini
    Oct 16, 2013 at 15:57
  • so to verify, I would need execute permission to use find? That would be the issue if this is true.
    – turbo
    Oct 16, 2013 at 16:41
  • You already have execute permission on find. I was adding as a FYI that if you want to search a directory, you need execute permission on it, but it seems you already have it based on your comment to the other answer. You can try the command find ./your/directory -not -executable -type d to list all directories that are not searchable.
    – ladaghini
    Oct 16, 2013 at 16:59
  • Ok as per my comment to you on the other answer, it was a symbolic link. Added the -L flag to find, and it works like a charm.
    – turbo
    Oct 16, 2013 at 17:34

This is happen because probably you don't have read permissions in someone else's directory. If you don't have read permissions, you can't view/search/find any content. You can check this with the following command:

ls -l /home/username/directory

Also be sure that those files or directories for which you search are really files or directories (first character from 10 character string permission is - or d, not something else - l in your case which stands for symbolic links).

ls shows permissions as a 10 character string, for example -rw-r--r--. The characters can be interpreted as TUUUGGGOOO where:

T Type
UUU   Rights for the owner of the file
GGG   Rights for users in the group
OOO   Rights for others, not listed above

T is one of:

- file
d directory
c character device
b block device
l symbolic link

Source: Introduction to Unix file permissions

Also, when you use:

  • find -type d - you search only for directories.
  • find -type f - you search only for regular files.
  • I do have read permission on that directory, I can use grep on it (which I believe implies that I do), and in fact using ls -l on it returned rwxrwxrwx
    – turbo
    Oct 16, 2013 at 15:11
  • @turbo And for the files/folders inside that directory do you have read permissions? Can you see something if you navigate there? Oct 16, 2013 at 15:12
  • The directory has about 200 directories and they are all set to rwxr-x-r-x and each directory has some files, I tested a few and they were all r--r--r--.
    – turbo
    Oct 16, 2013 at 15:14
  • @turbo Then you should speak with that user. Maybe he set other special permission on his files. I'm sure that there is the problem with permissions. What is the output of this command: ls -alR /home/username >/dev/null? Oct 16, 2013 at 16:43
  • @turbo When you say ls -l returned rwxrwxrwx, was there a d in front of that? Try ls -dl ./your/directory instead.
    – ladaghini
    Oct 16, 2013 at 17:04

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.