HTML Goodies: PERL Primer, Part 2
[Setting the Permissions]
I'm going to assume at this point that you have the ability to use PERL and set permissions on a server. We're going to go over two more preparatory steps in this primer:
- Creating your CGI-BIN
- Setting the Permissions
I know this is still a little boring, but stay with me; you need to know how the trick works before you can start pulling rabbits out of the hat, unless you already have a lot of hats that just happen to have rabbits.
Creating The Bin
First off, you're going to need a place to put all of your PERL scripts. The most common method is to set up a directory where all of your PERL scripts will sit. There are other methods of doing this. In fact, I've worked with server operating systems that don't require a directory to be set up. As long as the PERL script had the extension "cgi", it could sit anywhere. I wasn't fond of that. I set up the directory anyway.
If you want to do this a different way, by all means go ahead. I'm simply sticking with the method I'm most use to. So, let's make a directory, shall we?
I suggest you name the directory you are about to create "cgi-bin" as that is what I am going to call it the rest of the way through these primers. Please notice that is a hyphen between the "cgi" and the "bin."
The name comes from Common Gateway Interface-Binary. No, bin does not mean a place to put things, like a trash bin. So, let's make it. Again, I make my directories through Telnet. If you do it through your FTP program, go for it.
You'll want this cgi-bin at the first level of subdirectories inside the directory where you keep all of your Web pages. Log into your site at the highest level of the directory where you place your Web pages. At the Telnet prompt type:
That's UNIX for "make a directory named cgi-bin". Press return to enter the command. If you get another prompt and no error messages, you did it. Now type ls. That means "show a list of everything at this level". You should see the cgi-bin you just created.
If you don't see the directory, you may actually be in it. That happens sometimes. You need to get one level up again. Type cd.. (two periods). That changes directories up one level. Press "return" to get another prompt. Now type ls. That should display the cgi-bin.
Setting the Permissions
OK, we have the place where all of our PERL scripts will sit. Now we need to "turn it on". We're not going to technically activate it, we're going to set the directory's permissions so that it can play around with the script.
While you're still at the level where you can see the cgi-bin, type this at the Telnet prompt:
That means to "change the modification to 775 on cgi-bin". Press "return". You should now have another prompt. Success. You have set the permissions.
But set it to what? Well, to 775. Weren't you paying attention?
But seriously folks...these permissions will become your friends before we're done with these primers. Every script and file you create will need to have one permission or another set in order to work properly on the UNIX server.
I know it would be easy to just take me at my word that 775 is the correct modification, but wouldn't you be happier knowing what those numbers mean? I knew you would.
Dig this chart:
Moving from left to right:
- The ability to "read" a file is granted by the number 4 or the letter "r".
- The ability to "write" to a file is granted by the number 2 or the letter "w".
- The ability to "execute" a file is set by the number 1 or the letter "x".
- Finally, the setting to disallow all of the above is either zero or a dash.
We set those permissions three times:
- First Position: Owner
This is the person with permission to enter the directory. That's you.
- Second Position: Group
I have only run into a concern over this once and that's on my current server. A "group" is a series of users that all have permission to enter the site, yet do not all have permission to set permissions. That's the way is was explained to me. The owner is still the head honcho. I am one of a block of users, so I needed to set this number differently than I used to when I was the only one using the directory.
- Third Position: Other
These are those pesky visitors that show up to your site and want to view your Web pages.
OK, then! Back to that 775 deal. You can probably guess that it's not the number 775 (as in one less than 776), but rather three numbers setting the three permissions above.
The first number, "7" is allowing the owner the ability to read, write, and execute. I know that because 4 + 2 + 1 = 7. Get it?
The group also has that permission. Their number, the second number, is also "7".
But, oh those poor others. They only got five. They only have permission to read and execute. They cannot write to the files. 4 + 1 = 5.
Yes, I know that it would be easy to simply set all files to 777 at all times. Don't do that. Go with the permissions I suggest in the primers. You do not want to make it easy on someone who shows up and would like to write nasty things into your coding and such.
Here's Another Example"
Web pages only need permission set to 644. The owner needs to read and write, that's 6 (4 + 2 = 6). The group only needs to read, and the others only need to read. Web pages don't execute, so that's really the only permission you need to give.
What About Those Letters?
They're not as easy to grasp as the numbers and I've only used these a couple of times. Where I see them most often when a PERL script is set to alter permissions itself, or in a directory listing from a UNIX server. The permissions code 775 looks like this when applied to a directory:
That same code, when applied to a text file or image, looks like this:
You may have noticed that the difference between the two is the little d at the very beginning. That means "directory". If the item is a text file or an image, then the d is replaced by a dash.
It's pretty simple to get from here, you just break down the run of letters to equal out numbers:
Here's Another Example (Again)
The permission 644 on a text file or image looks like this:
If a d appeared in the first place instead of the dash, then you'd know it was a directory. Nothing to it.
Cool! Let's get a PERL script up and running and start tearing it apart. By the end of the next run of primers, you'll be able to create one of the coolest thank-you pages around, send personalized email to the respondent and a whole host of other things.
This is going to be fun...
[Setting the Permissions]