I updated my code in the original post.

Err... you shouldn't do that. It kind of kills the context for all the answers that you get. These nodes stick around. Say someone finds your question a year from now and starts looking at the replies and they don't match the code in your post? All it'll do is confuse them.

You can always post new code in a reply. Or just post another question. But before you do, how about not being so quick to give up on figuring it out yourself? You won't really learn anything by continually asking how to fix this or that and just sort of pasting the solutions in. Take a few hours to try to learn at least the basics of the language you are using.

Is this your first attempt at programming altogether?

Well, that's definitely progress, and your code looks a lot better, though I recommend re-reading and understanding the latter portion of my previous post so that you can re-work your greps.

But back to your modified problem: If your code now runs, but just doesn't output what you're expecting it to, it's time to pull out the age-old debugging tool: print. Pepper your code with print statements that output the current state of various variables, which logic paths you followed, and when you're inside of loops... that sort of thing. The actual Perl debugger could be helpful, but it's harder to learn. For a short script like yours, the shortest learning curve is to just sprinkle print statements all over the place.

The idea is to look at a line of your code and think up an assertion: "I believe that before this line @something contains X, and after this line of code, @something contains that." Now put a print statement before and after demonstrating that assertion, as well as whatever variables contribute to creating the change. Run your code. Watch your assertions do what you expect, or fail. When they fail, hopefully the print statements will give you enough of a clue regarding the failure that you can figure out why it's failing.

I followed your advice. I have narrowed my problem down to the comparison part of my code here:

foreach (@contentsOfDataBase){
  chomp ($_);
  print "$_";
  @inDirectoryNotInDataBase = grep {!"$_"} @contentsOfDirectory;
  print "@inDirectoryNotInDataBase", "\n";
}

foreach (@copyOfContentsOfDirectory){
  print "$_";
  @pdfNoMatchingDirectory = grep (!$_, @contentsOfDataBase);
  print "@pdfNoMatchingDirectory", "\n";
  
}
[download]

They're nearly identical so it is the same problem in both. I changed the structure of the grep function to see if that would fix it. It didn't. The problem specifically lies in the grep line itself. This is how I understand that block to work.

foreach (@contentsOfDataBase){
  chomp ($_);
  print "$_";
  @inDirectoryNotInDataBase = grep {!"$_"} @contentsOfDirectory;
  print "@inDirectoryNotInDataBase", "\n";
}

foreach (@copyOfContentsOfDirectory){
  print "$_";
  @pdfNoMatchingDirectory = grep (!$_, @contentsOfDataBase);#for curre
+nt element in @copyOfContentsOfDirectory find all elements of @conten
+tsOfDataBase that are not a match
  print "@pdfNoMatchingDirectory", "\n";
  
}
[download]

The special variable, "$_" is used both by grep, and by foreach. Write your loop like this:

foreach my $dir_try ( @copyOfContentsOfDirectory ) {
    push @pdfNoMatchingDirectory, grep { $_ ne $dir_try } @contentsOfD
+ataBase;
}
[download]

The 'it' variable ($_) from your foreach loop is being masked by the it variable from the grep. This avoids that situation. Also, on each loop iteration, @pdfNoMatchingDirectory is being reset with a new list from grep. I added push so that @pdfNoMatchingDirectory instead accumulates all the elements you're looking for. That may not be what you're after, so you might remove the push again.

You know, I keep seeing the word DataBase in your variables. It would probably be more efficient to use your SQL database's SQL engine to perform the set-symmetric-difference task.




Dave