I'm trying to create an array variable with a list of files to use in a small script, needing the full path to the file. Looking around I tried something like this:

find /path/ -t f | grep randomString

It turned out that this was returning only some of the files I needed, so I tried using wc -l with the previous command and with ls -R /path/ | grep randomString, getting different line counts (with a difference of more than 100 lines, so I'm counting the directories from ls -R out). I'm trying to see why find is not returning the desired results. Any ideas?

  • Are you sure ls -R did not list some symlinks, devices or other special files that you excluded with -t f for find? – Dubu Apr 30 '15 at 12:08
  • Good suggestion, but yeah, unfortunately there are no links, devices nor special files in the path listed, only CSV files. – Daniel Sanchez Apr 30 '15 at 12:28
  • Please show some sample output (it would have to be the full output from both find and ls -R for a sample directory). I don't see any evidence here that find is omitting entries that ls -R shows. ls -R has an overhead of about three lines per directory, and you're only claiming to account for one. – Gilles Apr 30 '15 at 20:47

find lists all the files in the directory tree. ls -R actually lists fewer files: it omits dot files — you need ls -AR to include them.

If you aren't finding the files you need, there are a few possibilities:

  • You missed them in the output. Use a search command (e.g. find … | less and use the / key in less). Keep in mind that the output of find is not sorted.
  • The files aren't actually called what you think they're called. Do a case-insensitive search if you aren't sure about the case.
  • The files you're looking for are actually symbolic links. Use find -xtype f instead of find -type f to categorize symbolic links as the file they point to.
  • The files are under a symbolic link to a directory. Use find -L to traverse symbolic links, but be careful: this could search a very large number of files if you have a symbolic link to a directory that's at the top of a large hierarchy.

In no case would ls -R find files that find doesn't.

You can't easily compare the number of lines in output of ls -R and find:

  • ls -R omits dot files, find doesn't.
  • ls -R has a total of three extra lines for each subdirectory (except for the root), compared with find -type f: the directory entry, the blank line that separates the listing of that directory from the previous line, and the header line with the directory name followed by a colon.
  • find -xtype f instead find -type f seems to work as I was expecting, though I'm almost sure that there were no symbolic links within the directories. Now that I have located the problem I can finally keep working on the script. Much appreciated! – Daniel Sanchez May 4 '15 at 7:30

When you execute ls -R you get as output the directories names in the listing.

  • True, I should have specified that the difference in the line count is too big and the results completely different when I don't pipe the commands through wc -l – Daniel Sanchez Apr 30 '15 at 10:33
  • Check also if ls do not return the results in one line and you grep one occurrence from several – Romeo Ninov Apr 30 '15 at 10:47
  • Checked, both commands return results in several lines when being piped through grep. – Daniel Sanchez Apr 30 '15 at 11:35

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.