Re^2: -e stransgeosities

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?

Comment on Re^2: -e stransgeosities

Replies are listed 'Best First'.
Re^3: -e stransgeosities by Corion (Patriarch) on Apr 23, 2012 at 13:49 UTC
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]
Re^3: -e stransgeosities by Jenda (Abbot) on Apr 23, 2012 at 23:33 UTC
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]