Ask Ubuntu is a question and answer site for Ubuntu users and developers. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

For a university project, I have to count all the files in a folder. I have used the command:

find ./dirName | wc -l

Although when I compare this to the file count provided by Nautilus it is considerably more. See the screenshot below:

enter image description here

./dirName is actually a directory of files from a repository (SVN/GIT) and I need to find out how many files make up the system.

Could anyone explain why these differences occur and maybe tell me which one is more reliable?

share|improve this question
Try to minimize the set of files on which you see a difference on (less than 10 items), then post a full directory listing (ls -al) as well as what you see in your file manager. We'll then be able to see what this causes. Now it's just guessing. – gertvdijk Jan 22 '13 at 22:30
"a directory of files from a repository (SVN/GIT)" That is very relevant information. Do you want the real file system based file count or the one reporting from your Version Control System? Git uses tricks under water, like hard links and hidden dot-files. You can expect a large difference indeed, depending the differences between branches. – gertvdijk Jan 22 '13 at 23:10
VCS? I want to know how many files, excluding directories are within the set of files downloaded from the repo. It is a git repository so you're probably right. Is there a way of counting the total number of files in the repository? – D4nC00per Jan 22 '13 at 23:12
That's a totally different question if you would ask me. Include the VCS you're using. For Git I'll be glad to answer that. But it's here already: How to get a count of all the files in a git repository?. Please include these relevant details from the beginning, it's a different question. – gertvdijk Jan 22 '13 at 23:15
That was just to get more help with my project. My main question was why there was a difference between the two numbers, which you answered very well. I very much appreciate your help. Hope I haven't n00bed too much. :) – D4nC00per Jan 22 '13 at 23:19
up vote 2 down vote accepted

Nautilus doesn't count hidden files.

Files and directories starting with a dot (.) are hidden in Linux.

Steps to reproduce:

mkdir somedir && cd somedir
touch .hidden .hidden2 regular regular2      # 4 files, 2 hidden
find . | wc -l                               # outputs 5 (4 files + dir itself)

Nautilus reports: Contents: 2 items, totalling 0 bytes

Using Git

Here's a quick demonstration on the amount of files for the metadata used in Git, all in the .git directory.

git init myrepo                              # Initialized [...] in myrepo/.git/
cd myrepo/
find . | wc -l                               # outputs 23! for an empty repository
tree -a                                      # outputs 10 directories, 12 files

echo "have to add something for git ls-tree" > somefile
git add somefile && git commit -m "Initial commit"
find . | wc -l                               # outputs 38 (!)
git ls-tree -r HEAD | wc -l                  # outputs 1

And also Nautilus reports 1 there.

My suggestion: use tree

As Gilles pointed out in his answer, using find and piping it to wc isn't overly reliable if the file names contain special characters.

It seems that tree is capable of doing this right:

tree -a
├── dir
│   └── regular3
├── dir2
├── .hidden
├── .hidden2
├── regular
└── regular2

2 directories, 5 files
share|improve this answer
so by default are files with . prefix automatically hidden? – D4nC00per Jan 22 '13 at 22:57
@D4nC00per Yes, all files/directories you start with dot (.) are hidden ones. In Nautilus you'll need Ctrl+H I believe, in listings using ls you'll need -a to show all files including hidden ones. – gertvdijk Jan 22 '13 at 23:00
Using tree -a ./dirName output 1180. Which is a different number again. I added further detail to the question. The folder contains folders such as .htaccess as well as .gitignore files. So I'm unsure as to count the "hidden" files or not as some are not hidden but hidden due to their filename by ubuntu. – D4nC00per Jan 22 '13 at 23:04
Ok, the count from tree is lower due to unreliabilities removed by using tree instead of find piped through wc – D4nC00per Jan 22 '13 at 23:09

There could be file names with newlines in them. Highly inadvisable, but technically possible. This may be what your exercise was about.

One way to reliably count the files under a directory is to make find print something that can be counted reliably, i.e. with one item per file.

find ./dirName -printf a | wc -c

Keep in mind that find includes dirName itself, and recurses into subdirectories.

If you only want the files inside dirName, without recursing, let the shell count them:

set -- *
echo $#
share|improve this answer
Nautilus also recurses into subdirectories with this file count. In that sense it's just a 1-off. You're right about the newlines. Counting by parsing the output to wc isn't really reliable. – gertvdijk Jan 22 '13 at 22:32
Is the bottom set of code terminal commands or a shell script? – D4nC00per Jan 22 '13 at 23:01
@D4nC00per Either. Run it in bash. – Gilles Jan 22 '13 at 23:12

Try checking the output of find:

find somewhere | less

You'll see that find by default outputs any kind of file, without making distinctions based on the type or on the name. Nautilus instead does not count the starting directory (somewhere in the example) or files that it would not show when browsing.

To solve the issue, use the -type option of find:

find somewhere -type f | wc -l
find somewhere ! -type d | wc -l

The first line will look for all regular files. The second all the non-directory items (i.e. regular files, block devices, UNIX sockets, and so on). See man find for more information.

You might be probably interested in reading about -H, -L and -P, which control how find should handle symlinks (and therefore how symlinks influence the counts).

share|improve this answer

Your Answer


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.