I did man perl on both hosts, and judging by the perl(some-number)delta sections shown, I'm assuming my old host runs Perl 5.8.3 and my new host runs Perl 5.004. Then again, while watching top on the new server, I do see perl5.8.3 as one of the running processes, so maybe they're both the same.
At any rate, I'm seeing behavior I can't explain, and my references can't get me out of. I have a subroutine called by static pages through an #exec cgi command, which sometimes opens or creates a file, then appends a line of data.
open(FH,">>$filename") ¦¦ die("Cannot Open File");
print FH "$output\n";
close(FH);
On the old server, the code works (obviously). On the new one, it doesn't. I tried the following issues; none led to a solution.
use Fcntl;When I try to research the issue (a.k.a. [google.com]) I come back to either the code that's already working on the old server, or the items listed above.
For the record, the text files are a backup to a database; I've half a mind to just let the data go into the database, and then have a separate script do a daily dump of new data into text files of the same name, but I'd rather get to the bottom of this error (there are other times I need to deal with text files ...)
Is there anything I've missed? Have any of y'all run into similar issues in the past?
A couple thoughts:
What are the permissions on this file? Create the file with the script so it's owned by it, then chmod 777 within the script. For this to happen, you will have to do it in a directory the script can write to, you may not be able to do so in your domain cgi-bin.
What's $filename?
$filename = '/you/may/need/full/path.txt';
You may not be able to write to the directory you're writing to. Also, add $! to show system error messages, this will give you a more detailed description on why it's dying:
open(FH,">>$filename") ¦¦ die("Cannot Open File $!");
print FH "$output\n";
close(FH);
Lastly I've had issues with some hosting's "virtual path." When I check the environment variables, it may show DOCUMENT_ROOT as /some/path/to/domainname.com but when I contact their admin it's an alias - /some/path/to/user34634345353/domainname.com. I think Netsol was one of these. You may see no such file or directory if it's this case.
For the record, the text files are a backup to a database
If this is mysql - look into mysqldump. You will love this program. :-)
# connecting remote requires hostname --h
$cmd = qq¦mysqldump -h $db_host --user=$sql_login --password=$sql_pass $db_name > $root/$datadir/$db_bu/$file¦;
$result = `$cmd`;
if ($result) { $result = "<li>$result<\/li>"; &html('Backup Error'); }
This writes a text file backup of the entire database. To recreate the entire DB, you log in to mysql as the database user, then
source /path/to/yourbackupfile.sql
Recreates an entire huge database in a matter of seconds.
I have a subroutine called by static pages through an #exec cgi command,
are you referring to SSI tags? If so, the new server does not support the exec tag, try the virtual tag instead.
<!--#include virtual="cgi-bin/yourscript.cgi" -->
As a shortcut you can also use this to and just have $filename as the filename only:
chdir("path/to/www");
Note there is no / at the end.
e.g.-
AddType text/html .shtml
AddHandler server-parsed .htm
AddHandler server-parsed .html
AddHandler server-parsed .shtml
Options Indexes FollowSymLinks Includes
