Lab Assignment #3

Due by 10:30 p.m. on Tuesday, February 2.

A. Reading

In the text, read the comments on style on pages 546-550, skipping any that refer to things you haven't had yet. It's time to start keeping style in mind in writing Perl scripts. We don't have to follow the style suggestions religiously, but when we deviate we should have in mind a reason why.

B. Problems to do but not to submit

• Type in and try these scripts mentioned in lecture. For sample files, you can use /usr/dict/words and files in the h directory.
  1. A script to replace one string by another in a text.
  2. A script to count the number of occurrences of each individual word in a text.

• To see how forgiving your browser is, make a file in your public_html directory with no contents except a little text (e.g., Have a nice day), name the file, say, little.html, make it readable to all, and try looking at it with your browser. Does your browser complain that HTML tags are missing, or does it just show it? If you make your text in two paragraphs, separated by a blank line, what happens?
• You can look at the HTML behind any web page by clicking on ``View'' in the browser and then ``Page source'' (or something similar, depending on the browser version). Some pages may have HTML than is messy and obscure, especially if they are created by programs or HTML editors, but others may be clearer. Try looking at some pages on the Web to see if you can find some good examples. You will understand some tags and not others.

C. Problems to submit

1. Write a script make_perl that will help get you going on any Perl project by making a ``skeleton'' script for you to start from. The usage will be

   make_perl scriptname where you can put any name you want for the script name.

   This script should check to make sure there isn't already a file by that name; open a file with the given name, for writing into; put the proper heading information in the file; and make the file executable by you, or if the name ends in .cgi, make the file executable by all.

   To do this, you'll need some Perl commands that will be discussed in section Thursday or lecture Friday, although you could also read up on them earlier: -e, open, print FILEHANDLE, and chmod or `...` or system(...).

2. If a browser is given a URL that is a directory instead of a file, the browser will look first for a file called index.html and display it if one is found. Make a personal home page by putting a file with that name in your public_html directory and making it readable by all. Its HTML tags should be based on HTML ideas that will be discussed in section and in class. Do what you want with it.

   However, it is not necessarily a good idea to put personal information on the Web. Also, this page will disappear after the end of the course. Therefore if you wish it can be an imaginary web page, with made-up information--but if you do that it might be good to label it as imagined.

   No need to submit this one, since it can be viewed directly.

3. This problem is the reverse of Problem 2.3.

   A simple database is usually organized into ``records'', each with ``fields''. An example is the roster database used in Problem 2.3, where each record is on one line and the fields are separated by colons. You wrote a script to take the roster database and print it out with each field on a separate line, preceded by a label giving the field name. Records were separated by blank lines.

   We treated this second form as just a report, but it's also a nice way to enter data in the first place, if it's up to you to make the original roster file. The only change you might want to make in the format is that instead of full field names, such as Name: Makam, Huli, you can use something shorter such as N: Makam, Huli . (One letter is enough since in this database the field names each start with a different letter.) Also, it's not necessary to line up the information vertically. After typing the data this way, you can use a Perl script to put the data into the original database form with colon separators.

   Write a script that does this. (As before, ignore the last two fields in the roster file; just don't make them.) In other words, the input to the script should be the same as your output in Problem 2.3 except for using one-letter field names and not lining up vertically; the output should be the same as the input in Problem 2.3 except for omitting the last two fields.

   Some considerations:

   • Since we're imagining that the data is typed in, it's going to be a little messier than the report produced in Problem 2.3. Your program should be able to handle reasonable messiness and check for unreasonable messiness.
   • Some kinds of reasonable messiness:
     • If the fields are out of order, your program should be able to cope.
     • The end of a record is marked by a blank line, but it would be easy for the person entering data to forget to put a blank line at the end of the input file. See below for suggestions about handling that.
     • If there are extra space characters before or after the field data, your program should handle that; see below.
     • If there is more than one blank line between two records, your program should handle that.

   • Unreasonable messiness:
     • If a field is given twice in one record (for example, two name fields) your script should complain and die. This will also catch the case where the data-entry person forgets to put a blank line between two records.
     • If a field-name letter is not a valid one, your program should complain and die; see below.
     • Some fields may not be critical, e.g., the email address. Just to be safe, though, it's good to require it always to be entered, even if the data part is empty. You could also allow the data part to be (no information) and use a substitution to change that to being empty.
   • In your script you can use a hash to associate the data with the field name.
   • When you have your fields in a hash, you need to get them in the right order, perhaps saved in an array (a list). You might loop through the field names in order, using push to build up the array.
   • To get data from the input line, one way to start is to test for a match with the pattern /^[A-Z]\:/ and then take all the rest of the line. (It's necessary to ``escape'' special characters, i.e., non-alphanumeric characters such as ()[]{}|, with \ when you are want them for themselves, for example \(, rather than using them as controls. A colon doesn't happen to be a control now, but it might be in a future version of Perl, so play it safe.) One way to get the rest of the line is to add a parenthesized part to your pattern: /^[A-Z]\:(.*)/ and then refer to $1, whose contents will be the part found inside the parentheses.
   • After taking all the rest of the line, you'll need to strip off any whitespace at the beginning and end. This takes two ``substitute'' commands s/...// where the part to substitute is empty. (What patterns are used?)
   • When you hit the end of a record, either because of a blank line or because of the end of the input, you'll need to check to see that all needed information is there and then gather it and print it out.
   • There is a Boolean-valued Perl function defined that tells whether a value is defined. In checking to see that all values are defined, your script might have something like

     unless (defined $data{$field}) or maybe

     defined $data{$field} || die ...

   • When you have read in all the fields, you can make an array with the data in the correct order and use the join function to get the output line.
   • After printing out, reset the hash to being undefined by using the undef function. Otherwise there is a danger that a missing field in one record might simply be replaced by the same data in the previous record--a very bad error!

   Here just some ingredients have been listed. You should think through the needed logic and plan the program yourself, but you can consult with the TA and instructor as needed.