Find the files algorithm

Question

I'm using Linux (Ubuntu 12.04). I'm trying to know how 'find' command works. My question is, how can I run and test the C files for 'find' which I downloaded from the GNU findutils ?

How do you mean how 'find' command works.? What are you trying to do? — , Mar 14 '13 at 17:35
Actually I'm trying to write a code that mimics 'find' from findutils package. I got a look at the find.c from the package files, but when I try to run that code using codeblocks I'm unable to compile it. — , Mar 14 '13 at 17:40
@Northstar what are you trying to do to mimic find? Would you consider saying "use perl and File::Find" (find2perl is a wonderful quick script tool) to do it for you to be an appropriate answer? Or is the problem the "using codeblocks I'm unable to compile it."? — , Mar 14 '13 at 17:55
Well I can write a script using python (Which I find it easier than perl). But thing is, I have to write a code in C which finds the files just like find from findutils package does. — , Mar 14 '13 at 17:56
@Northstar find can do many things - do you just want the "recursive descent and return a structure of the file paths"? Or something more? — , Mar 14 '13 at 18:14
@MichaelT yes I need a code that returns the structure of the file. — , Mar 14 '13 at 18:29
You haven't answered why you want to do this. To learn? To make find do something you are missing? Other? — vonbrand, Mar 14 '13 at 23:45
@vonbrand I have an assignment to do for finding files. I wanted to write a code similar to 'find' from findutils package. Btw, I downloaded the tarball from Debain's repos and got the code. Now I'm trying to figure out the code. — North, Mar 16 '13 at 02:41

score 0 · Answer 1 · answered Mar 14 '13 at 18:09

0

treatDirectory(dir) {
  open directory dir
  for each entry in dir
    if the entry is a match
      print it
    if the entry is a directory
      call treatDirectory(entry)
}

call treatDirectory(dir) for each directory given as parameter.

answered Mar 14 '13 at 18:09

Christopher Creutzig

101

1

This will quickly run out of file descriptors .... – Mar 14 '13 at 18:11
Will it? In a “proper” language, we have RAII or something similar, automatically closing the directory object at the end of the function. But, yes, that is one of the many things left as an exercise. – Mar 14 '13 at 18:16
Closing a file descriptor when the associated object goes out of scope is horrible design. Sometimes the file descriptor needs to remain opened. The handle to a file descriptor is not the programming language object, it's an integer, and that never goes out of scope. By the way RAII as a term is mostly unique to C++ (the concept does generalize). – Gilles 'SO- stop being evil' Mar 14 '13 at 23:20
Keeping a file descriptor open when the program no longer has any reference to it and therefore cannot use it anymore for anything, including closing it, serves what purpose exactly? (I did explicitly say “or something similar” to not limit the scope to C++. Ruby has a very nice design for this with File.open taking a block, for example.) – Christopher Creutzig Mar 15 '13 at 09:39
You're confusing file descriptors with file handles. A file descriptor is represented by an integer, not by a reference, it doesn't follow any language scope. Having block-scoped file handles (like with-open-file in Lisp, File.open(…) do … in Ruby, with open(…) … in Python, etc.) is good. But sometimes you need dynamically-scoped file descriptors, and then the library must not close the file under your feet. Also, closing a file open for writing may fail, so the time of closing must be carefully controlled: you can't let an asynchronous GC close a file when it's open for writing. – Gilles 'SO- stop being evil' Mar 15 '13 at 17:12
Seriously? I wasn't talking about file descriptors in the first place, I was talking about an object holding it. You said “closing a file descriptor when the associated object goes out of scope is horrible design.” And this type of problem is exactly why I think asynchronous GC is less useful than real destructors with well-known lifetime. It's not just about memory and file descriptors ... But let's not hijack this comment area for a discussion, ok? – Christopher Creutzig Mar 15 '13 at 18:56

score 0 · Answer 2 · answered Mar 14 '13 at 18:16

More of a question for StackOverflow but I've got this code lying about.

To find the right way to go about it, analyzing the source code for find will yield a m much more proper lesson. You don't really have to have it run to figure out what it's doing, you can read each line and google what you don't understand. But stepping through it with a debugger might help. If you have problems compiling it, take it to SO or whatever other resources you have to help you with build environments.

#include <dirent.h>

int doSomethingWithTheFileSystem()
{
  DIR *directory;
  struct dirent *whatDoesEPstandfor; //seriously, you terse C bastards just HATE new guys don't you?
  int count = 0;
  char filename[50]; //This is going to bite you in the ass when you have a filename larger than 50. Seriously, don't do this. 
  FILE* file;

  directory = opendir ("."); 
  if(directory != NULL)
  {
    while((whatDoesEPstandfor = readdir(directory)) != NULL )
    {
      printf("Looking at: %s\n",whatDoesEPstandfor->d_name );
      if(strstr(whatDoesEPstandfor->d_name,"thatThingYouAreLookingFor") != NULL)
      {
        printf("Found it at: %s\n",whatDoesEPstandfor->d_name);
      }
    }
    closedir (directory);
  }
}

Find the files algorithm

2 Answers2