if ( -e $file_to_check ) <-- error in AIX 6.1

[Richard]

We're seeing different behaviour with our Perl scripts after upgrading
from AIX 5.3 to AIX 6.1. Here's a example that shows the issue:

#!/usr/bin/perl -w

use File::Find;
use File::Basename;


$file_to_check = " ";
if ( -e $file_to_check ) {
print "File found\n";
}
else {
print "No file found\n";
}


When I run this under AIX 5.3 I get

No file found

But under AIX 6.1 I get

File found


In our actual code the filename is passed to the script. Sometimes
it's blank. In AIX 6.1 it says the file is found even though it's a
blank filename.

This is the perl version string from both AIX 5.3 and 6.1

This is perl, v5.8.8 built for aix-thread-multi


While we could change our code to deal with this, it seems like it's
not working correctly under AIX 6.1.

Anyone else on AIX 6.1 that can verify the behaviour?

Thanks for any help.

Richard

 

[rmcgorman]

Nevermind. It turns out we had a file that had a blank filename in the directory where we are running the perl.

There must be a good reason to allow it, but having Unix allow a filename that's blank seems bizarre, and can lead to confusing situation like this one.

 

[Tim McDaniel]

There must be a good reason to allow it, but having Unix allow a
filename that's blank seems bizarre, and can lead to confusing
situation like this one.

Speaking broadly, UNIXY systems tend to be permissive instead of
enforcing what the developers think is reasonable, the which notions
often enough do not match my own notions of reasonable.

Or, more briefly, UNIXy systems are X-Acto(TM) knives, not kiddie
scissors.

 

[Uri Guttman]

r> Nevermind. It turns out we had a file that had a blank filename in
r> the directory where we are running the perl. There must be a good
r> reason to allow it, but having Unix allow a filename that's blank
r> seems bizarre, and can lead to confusing situation like this one.

i would have checked that first as i trust the perl code to be
reasonably sane. nor would i think an os upgrade would break something
as core as that. as sherlock holmes would say, the answer has to be
elsewhere and the only logical thing is there must be a file named ' '!

as for filenames, all chars are allowed in them in unix flavors but / as
that is the dir delimiter. and as far as i can tell you can't have a
file with no chars in it.

uri

 

[Tim McDaniel]

as for filenames, all chars are allowed in them in unix flavors but /
as that is the dir delimiter. and as far as i can tell you can't have
a file with no chars in it.

There can be restrictions based on the filesystem. In general, you
can't use "/" or the NUL byte (all 0 bits). Indeed, you can't seem to
create or use a zero-length filename per se in the ext3 filesystem,
though I can't find an authoritative source, and when in a longer
path, it's ignored ("./" == ".", "/home//tmcdaniel" ==
"/home/tmcdaniel").

 

[Uri Guttman]

TM> There can be restrictions based on the filesystem. In general, you
TM> can't use "/" or the NUL byte (all 0 bits). Indeed, you can't seem to
TM> create or use a zero-length filename per se in the ext3 filesystem,
TM> though I can't find an authoritative source, and when in a longer
TM> path, it's ignored ("./" == ".", "/home//tmcdaniel" ==
TM> "/home/tmcdaniel").

that was my whole point to the OP. and i forgot about 0. it can't be in
a filename because it delimits the string in system calls. if the call
used a length param it could allow 0 in filenames. '' as a name makes
little sense to allow as you say it will reduce to the path anyhow.

uri