misterperl has asked for the wisdom of the Perl Monks concerning the following question: 

perl 5.8.8 on a recent fedora:

I was attempting to see if the same file existed in two directories. So I set up:

my $d1 = 'mydir/filename';
my $d2 = 'myotherdir/filename';

print "both places" if -e $d1 && -e $d2;

............

Both directories already exist and I have full access to each one and own each one. 

Then I placed the file in the dir in d1, and NOT in the dir in d2, and ran the script. It printed "both places"... 
*TILT*


So I pulled it into the debugger and broke at *if*. Then did

dbg> x -e $d1
0 1


dbg> x -e $d2
0 undef


dbg> x $d2
0 '/myotherdir/filename'

then I cut /myotherdir/ form the result and dropped to linux and ls'ed it and there it was, no issues.

HOW would -e return undef on an existing dir to which I have 777 access? to make matters worse, I then tried

if ( -e $d1 && defined -e $d2 && $d2 )

and it was TRUE! I checked inside the loop and -e $d2 was undef, yet this statement returned true.

.......
I ALSO went to the docs for -e and I didn't see ANY conditions described in which it would EVER return undef (although I might expect it to, if the dir structure was improper, etc so perhaps the docs are incomplete). But in my case, my directory is correct.
..
Fridays are sposed to NOT go this way.. ack!

Replies are listed 'Best First'.
Re: -e stransgeosities
by Corion (Patriarch) on Apr 20, 2012 at 15:07 UTC

    You seem to be using relative filenames. Maybe your current directory is not the same.

    my $d2 = 'myotherdir/filename';
...

    [download]

    Here you seem to be using absolute filenames:

    dbg> x $d2
0 '/myotherdir/filename'

    [download]

    Maybe your variables $d1 and $d2 are not what you think they are. Print them before doing the checks. Maybe they contain unexpected whitespace or unexpected slashes, or just are not what you expect.

    Also, you are talking about "directories", but then have /filename in your paths. I suggest that you post the output of find . together with a short script that does the operations you mention. In most of such cases I've encountered, the variables tested didn't contain what I expected.

[reply]
[d/l]
[select]
Re: -e stransgeosities
by pvaldes (Chaplain) on Apr 20, 2012 at 15:42 UTC

    I was attempting to see if the same file existed in two directories. So I set up...

    No, this is not the way. Two files can have the same name in different directories and have very different contents. The same file can be saved also with a different name.

    You could install and use fdupes

    print `fdupes -S /path/to/myfirstdir/ /path/to/myotherdir/`;

    Or read this node: Find duplicate files.

    The idea is to compute the md5sum of your target and look for a file with the same md5sum, i.e. with the Digest::md5 module.

[reply]
[d/l]
      thanks for the replies. I tried it with both relative and absolute paths- same result. And As I said, I cut and pasted the directories from the debugger and *ls'ed* them and they are fine ;so there appears to be no oddball characters.

I should have been more accurate and said I was looking for duplicate file NAMES, not contents. I don't really care what's in them. 

Basically the questions are 

(a) why does -e valid_file_path return undef, and 

(b) why does (defined $a && $a) return TRUE when $a eq undef?
[reply]

        Please, instead of showing excerpts from debugger sessions together with some narrative, write and show a short program that replicates the steps you did. This makes it far more clear what you did and what results you get.

        A rough start could be:

        #!perl -w
use strict;
my $d1 = '/this/file';
my $d2 = '/that/file';

for ($d1, $d2) {
    print "[$_] " . (-e $_ ? "exists" : "does not exist") . "\n";
};

if (...) {
...
};

# Show the contents of the directories in question
system("find /this /that");

        [download]
[reply]
[d/l]

        Ad a) Because the file path is not valid. I bet there is some whitespace character in the variable.

        Ad b) So $a is not undef, it just eq undef. Waitasecond ... an empty string is defined, yet equals to undef. Or maybe I should say undef gets turned into an empty string in a string context?

        Jenda
        Enoch was right!
        Enjoy the last years of Rome.

[reply]

Back to Seekers of Perl Wisdom