a script running in my browser

Do you mean a script running on your server as cgi called by the browser?

Or are you talking about some java/javascript actuality running in the browser

For as far as i know, perl doesnt run in a broswer

In the first case i would first wonder what userid/group the cgi is running under. You may be trying to write somewhere that your userid has access to, but the web-server does not

In the second case, i would kinda suggest you just give up. There is supposed to be a very restricted environment presented by the browser called "the sandbox" and most activity outside that is curtailed. A quick google search has again suggested that writing files under the browser is not easy, one suggested sending what you wanted to write back over tcpip to a server process/cgi that sends it back as a downloadable file the user can then accept.

I am talking about a script, one called sitemap.pl, that opens in my browser and displays html content. At the end of the script, I have it write a list created in the script to a file. sitemap.pl, opened in the browser, can not write to sitemap.txt in the same directory as sitemap.pl unless the text file's permissions are set to 666.

So, from what I am gathering here, I have to set write files to 666 so that the output from scripts running in the browser can write to them.

No matter how hysterical I get, my problems are not time sensitive. So, relax, have a cookie, and a very nice day!
Lady Aleena

How do you open sitemap.pl in your browser?

You may find it of interest to run this

      my $user = `whoami`;
      chomp $user; 
      my $groups = `groups $user`;
      chomp $groups; 
      print "<br>I am running as $user in groups $groups\n";
[download]

I suspect that the user you get back is not what you expected. I also suspect it is the last 6 in 666 that is fixing your problem. You are setting up a file that anyone can write into. Knowing what groups you are in and the perl process is running you may be able to determine what groups you may have in common. Setting that file (or directory) to be a member of that common group may mean you dont need to let anyone write to that file, but limit it to only userids in that common group.

I've looked at open and nothing popped up at me say this is where permissions are granted.

Filesystem permissions are governed by the operating system. As you don't say which O/S you are using it's a bit tricky to give specific advice. If using a Linux-like system see the TLDP entry.

Try changing the path to be your scratch area - it is likely that the webserver process user has permissions to write there.

"Please tell newbies to die to always include the $! at the end. If I had $! at the end of my die message, it would have cut at least 15 minutes of me traversing directories thinking the file did not exist."

We do, all the time. It's also laid out in nearly every single example in the open documentation you linked to.

"I've looked at open and..."

"Please tell newbies to die to always include the $! at the end. If I had $! at the end of my die message, it would have cut at least 15 minutes of me traversing directories thinking the file did not exist."

Not sure how you missed this, it's in the open documentation, all the examples and you have been told about using this before (e.g. Creating a random generator). Also, consider avoiding File::Slurp due to issues.

You don't want a file with 666 permissions - that means it's world writable: anyone can modify it (very poor security). The first thing you need to do is figure out what user the web server is running as. I think the default user for apache on debian is www-data. If you're using apache, the main config file should be located here:
/etc/apache2/apache2.conf
Inside there should be something like this:

User www-data
Group www-data
[download]

If it's something different (i.e., "nobody" or "apache" - just make a note of whatever it is).

Your cgi script will be running on the server as that user (not as you), so that user needs write permission to the file you want it to create. Also - the containing directory must be writable by that user (have write and execute permission).

So you need to do something like this on the server (don't type the inline comments):

cd /path_of_your_choice_goes_here
sudo mkdir webapp_output_files     # create directory to hold your files - name it whatever you like
sudo chown root:www-data           # set user:group ownership - note that the group should be the same group that the webserver runs as
sudo chmod 775                     # note: this gives group write permission

Now any user belonging to the www-data group should be able to write files into that directory. Run your script and see if that works. Make sure your writing the file into the webapp_output_files directory (or whatever you chose to call it). The file create should have owner:group of www-data:www-data, and the permission bits should default to either 664 or 644, depending on your umask setting.

I hope that helps. Good luck!

Maybe this is overkill?

Overkill? Well, having locks and ignition keys for our cars might be overkill, too, because a simple switch would suffice. Imagine: never again having a problem about forgotten or lost keys. The problem is that then anyone could drive away with your car, just as 666 allows anyone to write anything into your file…

I don't have a one size fits all "standard coding procedure". I do things one way when the program is for me or perhaps for another tech professional. I do things differently when the target user/audience has minimal tech skills. Anyway knowing what the basic options are is a good idea for folks who write the code.

We always have. In fact, you were told this very thing in the past but you disregarded it.