As far as your "No such file..." message, one way to verify that the file does exist is to either use stat() or something like -f $path to check it's existance, but open() should work ok for this. Also, make sure you are either using a full path on the open() call or that you really are chdir'd into the correct directory.

I wish I could. It is esentially thousands of lines long including the packages it uses. It also uses other subsystems. When I make a snippet with the open that gives me a problem, it works correctly. It might be hard to come up with a solution. Even if I could get some ideas, I'd appreciate it. I'm kind of stumped. Thanks.

Look very hard at the code you stripped out, that caused it to work. It must be something you trimmed out.

Cheers,
Sweetblood

I don't know what's bit you, as $! should really get set if open returns false. Just one thought: if there are signal handlers set, they should localize $! if they do anything that might effect it. I've been bitten by that once using signal handlers. (Don't assume that a function does not change $! just because it's not documented. Also, a function may still change $! if it succeds, as it may have called other functions that have failed.) Also check if you are really calling the builtin open function, not just a function that shaded it.

Update: also, make sure that the open call really returns false, it's not just you thinking it failed because you can't read the filehandle or similar simptoms.

Have you tried using the perl debugger?

If you have identified the particular open statement that causes the failure, and you can work out the line number of that statement, run the script with a command line like this:

  perl -d  name_of_script [...]
[download]

That runs the script via the perl debugger, which starts by giving you a prompt for what to do next. At this point, it's handy to have the source code on display in a separate window (e.g. in an editor).

The first thing to do is "b NNN" (where NNN is the line number of the open statement in question). This sets a breakpoint at that line, so that the debugger will stop execution and prompt you for more things to do just before it executes the chosen line. After setting the breakpoint, enter "c" to "continue" execution of the script, and wait for it to reach the breakpoint.

Once execution stops, use the "p" command to inspect the values of relevant variables, to confirm that they contain what you expect. Read the "perldebug" man page, and try the "h" command in the debugger for more pointers on what you can do.

Thanks again.

The "right direction" is always in reducing your code until the error goes away, and then adding code again, until the error reoccurs.

In many cases, the process of properly preparing the failing script for posting here, you will find the error already.

If you expect people to use magic or employ ESP remotely via the internet, you'll have to wait for the release of PSI::ESP I guess.

Good point Corion. I'll widdle it down. I'm in the process of doing that but the error only seems to happen after about 10 hours of processing. Unfortunately the error seems to happen in the most intense part of the script. I reduced the intense part to about NIL and the problem wen away so it's in there somewhere. This is going to be a tedious task and I'm still working on it. I was hoping someone would say "Oh yea, I've seen this problem...". I'll get there I guess.