TrinityInfinity has asked for the wisdom of the Perl Monks concerning the following question:

Hi Monks - I have a puzzle. I have several scripts in my collection, the main one is of course, main.cgi and it calls other scripts as needed using this format:
@execute = ("gettersubscript.cgi", "$var1", "$var2"); system(@execute) == 0 or die "system @execute failed: $?";
In my subscript, I have a very standard open the file, print a line to it, close it set of statements - but it will not work for the life of me! Here it is, plain vanilla:
#!/usr/bin/perl $file = "current.txt"; print "file to open is $file \n"; open (FILE, ">>$current") or die "Unable to access $file:$!\n"; print FILE "testline \n"; close FILE;
I have copied and pasted this exact code from the subscript into it's own file, which ran perfectly. And I've 777'd the text file a million times, as well as the directory it's in to make sure there are no write problems. Has anyone encountered anything similar? The only thing I'm doing differently from usual is calling a subscript with the system command - should I use something else instead? Backticks?

Replies are listed 'Best First'.
Re: File protection in a called script
by particle (Vicar) on Nov 15, 2002 at 16:01 UTC

    try use CGI::Carp qw/fatalsToBrowser/; in your scripts. this will spit errors out to the browser. of course, you should use CGI::Carp in development only. you probably don't want potential black hats to have access to your error reports.

    as a side note, you shouldn't quote variables unnecessarially, as in

    ## DON'T! @execute = ("gettersubscript.cgi", "$var1", "$var2"); ## INSTEAD, DO @execute = ("gettersubscript.cgi", $var1, $var2);

    you may accidentally stringify a variable that shouldn't be stringified, leading to subtle bugs (though probably not your current problem.)

    ~Particle *accelerates*

Re: File protection in a called script
by VSarkiss (Monsignor) on Nov 15, 2002 at 16:25 UTC

    "will not work" is not very specific. Is the file being created but is empty? Is it not getting created at all? What error messages are you getting? (If none, you should add some diagnostic messages.)

    However, I'm going to guess that you're trying to write into the directory where the CGI is executing, and you don't have permission to do that. Try putting in an absolute path for the file name: $file = '/tmp/current.txt'; #or some suchRemember, the directory that the file is in is not necessarily the current directory when it executes.

    HTH

      "My bad" sums it up nicely, I didn't write specifically what was going wrong.

      In the subscript - it doesn't appear to write to the file. I've set a variable to trap the returned value of the Open statement, and it opens the file allright! But when I've tried to read lines out of that file (@lines = <FILE>, or while <FILE> print $_), nothing prints. Nothing is written. It's a mystery to me.

      I also tried at this same point in the script to simply copy the file to another, using system(`cp file1 file2`) as well as regular backticks. In both cases, the created file is size 0! But as I said above, all these tricks I've tried in a standalone script, which runs fine. Bizarre!
        What does the file contain after the script is finished running? What happens when you run the script from the command-line passing the same arguments? Also, you might want to check the return values of the print and close calls. Those can sometimes fail (although usually not for files) especially if the disk is full.
Re: File protection in a called script
by Thelonius (Priest) on Nov 15, 2002 at 17:38 UTC
    If that is your code exactly, no wonder there's a problem. Of course if you use strict; and perl -w, you'll probably find what's wrong.
      I do use strict and -w, it produces no warnings regarding the file opening/writing.
        Then you should copy and paste your actual code instead of the above, which has an obvious bug: you are opening $current instead of $file.