In my experience, the permissions of the calling HTML file have nothing to do with the permissions of the perl script. If it pulls it up for editing, that seems to imply that your CGI files aren't set up to execute, even if they have execute permissions. I'd recommend the following:

Type in the filename into your browser. I.e. something like http://www.myserver.com/cgi-bin/myfile.cgi . If you load that page, and it still pulls the file up for editing (as I'm imagining) then the problem is NOT in the HTML file, but in the CGI file.

If this is the case, I recommend the following:

* If you're running ActiveState's ActivePerl, then it should (usually) assign .pl for your perl file extension. Rename the .cgi file to a .pl file and see if that works.

* Double check your execute permissions. In IIS, there are two or three places to check these, most of which are in the Internet Services Manager. You have to click on your website, and you may need to create a 'default application'. (right click on the website name in IIS' manager app, it's somewhere at the bottom of one of the Properties pannels) I don't know why, but if you don't create an 'application' for the executables to run in, it won't always work. The second, is to right-click on the Directory properties in IIS' manager, and make sure that the Execute bit is enabled for that directory. The third, of course, is to make sure NT's filesystem (NT Explorer) allows read AND execute access. * If you're running a *IX system, your file permissions should be set to 755 or 777 (777 only if your cgi is supposed to write a file) and you should have the line #!/usr/bin/perl at the beginning - or an equivalent pathname to your perl interpreter.

andre germain
"Wherever you go, there you are."