Project 2 -- fork(), exec(), and wait()

Electronic Copy Due Tuesday, November 1, 1:00pm

Hard Copy Due Tuesday, November 1, 1:30pm

NOTE: This assignment, like the other projects in this class, is due at a particular time, listed above. This means that if you are even a minute late, you lose 20%. If you are worried about potentially being late, turn in your project ahead of time. Do this by submitting it electronically before it is due and giving the hard copy to me during office hours or by sliding it under my office door before it is due. Do not send assignments to my personal email address. Do not leave hard copies in my departmental mail box or attempt to give them to departmental staff (who cannot and will not accept them).

As discussed in class, one way to build an application is to use existing applications that each do a part of the job you want your new application to do, then tie them together and add whatever additional functionality is needed to make the whole system work. Consider, for example, working with files in Portable Document Format (PDF). Imagine, for instance, that you want to have a system that allows you graphically browse through directories or zipped files of PDFs. You could, of course, build this from scratch, writing your own software to zip and unzip sets of files, parse PDFs and display them in various ways suitable for browsing, etc. Alternately, you could using existing zip/unzip, file conversion, and graphical browsing programs, and tie them together with fork(), exec(), and wait(). Because the latter approach is much less work, it is the approach you will take in this assignment.

In this assignment, you will take the first step toward the development of a graphical PDF browser. This is only the first step, since you have not yet learned in this class about mechanisms for passing the input and output of processes to one another (although you will!), you have not yet learned in this class about mechanisms for reading directory entries (although you will!), and you are not assigned the job of creating a nice GUI front end for your PDF browser (since that is a topic for another class). Still, it will let you gain experience with the basic mechanisms for using other applications to accomplish goals for your new application.



The Assignment

You are to create a program called gbPDF to graphically browse PDFs. The user will invoke gbPDF as follows:

gbPDF FILENAME1 FILENAME2 ... FILENAMEn
All filenames are expected to have a .pdf or .PDF extension. Filenames with other extensions or none at all should be ignored. All other command line arguments should be ignored as well. When run, gbPDF will do the following:
  1. Create two sets of .png files corresponding to the .pdf and .PDF files given as arguments to gbPDF. The first set should be "full sized" images of the PDF document (suitable for reading 10 point fonts in the original PDF) and a set of small "thumbnail" images, each no more than 120 pixels high. If there are any problems creating these images, gbPDF should notify the user of that fact and exit with exit code 1. Otherwise, gbPDF should proceed to Step 2.
  2. Generate an html page that lays out the PDF thumbnail images in a grid. In particular, all pages from a single PDF should be in a single row and each PDF document should get its own row with the name of the PDF file in the first column. The name of the PDF should be a clickable link to the PDF itself, while each thumbnail image should be a clickable link to the full sized image of that page. If there are any problems creating this page, gbPDF should notify the user of that fact and exit with exit code 2. Otherwise, gbPDF should proceed to Step 3.
  3. Launch the user's preferred web browser to display the html page created in Step 2. To determine the user's preferred web browser, gbPDF should look at the BROWSER environment variable. Once the browser has been launched, gbPDF should exit with exit code 0. If BROWSER is NULL or unset, gbPDF should let the user know that fact and exit with exit code 3 without displaying the html page.



What to Turn In

You will turn in both a hard copy and an electronic copy of your assignment. Electronic copies must be submitted to the appropriate drop box in D2L for the course. Do not send them to my email address.

Both the hard copy and the electronic copy will contain a cover sheet documenting group membership and contributions (see below), all source code you created for gbPDF and a write-up of 1/2 to 1 page (roughly 80 characters per line, 50 lines per page) explaining the data structures and algorithms used in your code. This page limitation does not include figures used in your explanations, which are encouraged and may take up any amount of space. (The explanations do not remove the requirement that your code be well commented.)

The electronic copy will also contain an executable for gbPDF which should be called gbPDF.

Your source code should be well structured and well commented. It should conform to good coding standards (e.g., no memory leaks).



Other

You may write your program from scratch or may start from programs for which the source code is freely available on the web or through other sources (such as friends or student organizations). If you do not start from scratch, you must give a complete and accurate accounting of where all of your code came from and indicate which parts are original or changed, and which you got from which other source. Failure to give credit where credit is due is academic fraud and will be dealt with accordingly.

As noted in the syllabus, you are required to work on this programming assignment in a group of at least two people. It is your responsibility to find other group members and work with them. The group should turn in only one (1) hard copy and one (1) electronic copy of the assignment. Both the electronic and hard copies should contain the names and student ID numbers of all group members. If your group composition changes during the course of working on this assignment (for example, a group of five splits into a group of two and a separate group of three), this must be clearly indicated in your cover sheet (see below), including the names and student ID numbers of everyone involved and details of when the change occurred and who accomplished what before and after the change.

Each group member is required to contribute equally to each project, as far as is possible. Your cover sheet must thoroughly document which group members were involved in each part of the project. For example, if you have three functions in your program and one function was written by group member one, the second was written by group member two, and the third was written jointly and equally by group members three and four, your cover sheet must clearly indicate this division of labor.

Note that all personally identifying information (names, student ID numbers, 4x4s, etc.) must only be included on the cover sheet and nowhere else in the project materials.

For creating the sets of png files, I recommend that you consider using the ImageMagick convert program.