1) In this line:

if (!(open (OUT, ">$_"))) { print "Error opening file $_ 
   for writing."; exit 0; }
[download]

if(!open(OUT, ">$_")){
    print "Error opening file $_ for writing: $!";
    # $! holds the error mesg
    exit 0;
}
[download]

open(OUT, ">$_") or die "Can't open $_ for writing: $!";
[download]

But it doesn't seem to get to this point, so this isn't the source of the troubles. 2) some more information would be useful. You have the line:

print ">$_";
[download]

This reply didn't mention two other things with the original code that should be pointed out. First, you are not using -T (read perlsec and perlrun). Second, you aren't using -w or strict (perldoc strict and perlrun). You should NEVER NEVER NEVER NEVER create a file based on raw user input which you are doing. This is BAD BAD BAD. Learn now before you learn the hard way. You seem to use tr// to help make this safe, but it isn't the best way, and safer programming is better programming. Look at Untaint.pm for untainting of the input and read perlsec, twice. Also, I see no reason why you are using $_. Also, please skim this node but really pay attention to the comments I made on that node following it. It deals with file locking. You have no file locking here, and possibly do not need it, however you should take a look and familiarize yourself with it if you are using text files and not a DB.
swiftone is right about looking at CGI::Carp. It is a great tool for debugging CGI, just add this in your script:

use CGI::Carp qw(fatalsToBrowser);
[download]

and you will get more useful error messages to the browser, most of the time at least :)

Cheers,
KM

Why are you using c-style comments? If these are in your code, then there's your trouble.

$query = new CGI;
[download]

name=Irving
color=Blue
money=happiness
[download]

$query = new CGI(FILENAME);
[download]

If you haven't used "new CGI" the program will run without asking for name/value pairs.

This may seem like a bit more work up front, but I find that it allows for a lot of quick and dirty debugging from the command line. You may also want to look into the Perl debugger. Once you get used to it, it's a wonderful tool.

Final note: not to be redundant, but the others are right when they say to never create a CGI script without -wT and use strict. A good source for initial information is a brief overview of Safe Scripting in Perl that can be found at perl.com. Also, on a Linux or Unix system with perl documentation installed, enter the following at the command line: <CODE> perldoc perlsec </

You're getting the error:

    > Software error:
    > Insecure dependency in open while running setgid
[download]

which means that your software is doing something good and right. You said earlier that you weren't yet worrying about security in your scripts... well, you should be happy that you're getting this error, then! It means that at least you have software looking out for your security.

Anyway, if you read perlsec, you'll find that this error is occurring because you're using tainted data--data that's coming from a source external to your program. This is a problem in a CGI environment, because you don't control the input to your script. And in fact, the example you use is a huge security hole.

To untaint your data, you can check run it through a regular expression that checks for safe characters, then grab the safe characters and use those for your filename. perlsec has this example:

    if ($data =~ /^([-\@\w.]+)$/) {
        $data = $1;                     # $data now untainted
    } else {
        die "Bad data in $data";        # log this somewhere
    }
[download]

So you can do something similar to your $nameoffile variable. Run it through a similar regular expression and then set it to $1.

Read perlsec so that you write secure code.

By the way, you also said this:

    > #By the way when I tried to use 
    > #$nameoffile=$query->param('nameoffile'); it returned the
    > #error "..param must be part of some structure..."
[download]

That code tries to call the param method on the $query object. You don't have a $query object defined, so you can't call a method on it. Just using

    param('nameoffile')
[download]

like you are should work fine.

1. Yes, print "<$_"; prints a perfectly good path.
This stumps me then. Although I'm not up on the tr// operator...what happens if you comment that out and try "safe" names (such as "aaa")?

2. I don't care for security so far, all I want to understand is why when I enter ,say, myfile.html in a form, it UNDERSTANDS it, spits it out at the print ">$_"; line, and seems to behave PERFECTLY WELL ..EXCEPT when it gets to the open file line.
Well, I'm sure KM has already given you a security rant. I'll just add that it's easier to include security from the start than it is to rewrite. That said, I understand your concerns about understanding what is going on.

Let us know what kind of warnings it generates.

Averall I like Perl very much. Reminds me a lot of C (my favorite language of all time.)
Soon you will love perl more. (near) Equal power, much easier to program. C will always have it's place though (gotta write the perl interpreter in something :))

When will you start caring about security? When you write a big hole in your code and you get hacked? Even when I paint the front door to my house, I keep a lock on it. Learn to do everything the right way, right away.

Cheers,
KM