in reply to Re: file testing is hard
in thread file testing is hard

What I've learned, through various approaches, is that you want to depend on the result of open() (or sysopen()). A file might exist, for instance, because -e "file" returns true, but you still might not be able to open it
But you then go on to use -r in your code to check if a file is readable with the current effective UID/GID. I was going to point you at exactly that operator to solve your "file exists, can I read it" problem. The various -X operators cover all of the various situations the OP mentioned.

Replies are listed 'Best First'.
Re: Re: Re: file testing is hard
by dpmott (Scribe) on Dec 01, 2003 at 23:38 UTC
    True, that.

    In practice, I usually dispense with such filetests and just go straight for the open(). But then, I usually program on win32, where that's okay.

    I seem to remember, though, that it's perfectly legal to open directory entries, block/char special files, etc on a UNIX filesystem. I included those specific tests to cover those cases. You (probably) don't want to read your persistent INI from a serial port, nor save it to a directory inode.

    I didn't check for read/write permissions, because open() will do that. Also, it encourages checking the return value of open(), which was most of my point -- it avoids code like this:
    if ( -r $file ) { open(FILE, $file); # hmmm... is the file open or not? my @contents = <FILE>; close FILE; # process @contents; }