Project 2 -- fork, exec, and wait

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 the due date (the electronic copy is what is due by the time given above) then giving the hard copy to me or the TA during office hours or by sliding it under my office door (the hard copy is due within twenty-four hours after the electronic copy is due). Do not send assignments to my personal email address or to the personal email address of the TA. 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, part of the UNIX program design philosophy is not to create each application from scratch but, rather, to build new applications by utilizing existing programs. One way to tie these programs together is to spawn off child processes using fork and run the programs using exec.

One application that people often enjoy is playing videos on their computers. Unfortunately, it is sometimes difficult to find an appropriate video player for a particular video file. This is because, while developers of video players often try to include functionality for most known video formats, the inventors of new video formats often stay one step ahead of the video player developers (generally for reasons that have nothing to do with technical superiority and everything to do with trying to keep content in proprietary formats for financial reasons). This means that users will sometimes encounter video files that their favorite video player cannot play.

One solution to this is to develop an application that assists users in finding video players for their video files. This program could work by simply trying to play the user's file using the various "known" video players on a given system and seeing which player works for the given file. The new code could "know" about these players from several sources, including having pathnames hard coded within it, reading environment variables, searching the user's path for known players, searching the file system for known players, getting pathname and/or player name information directly from the user, or some combination of these. The searching could be done using existing utility programs. Using fork, exec, and wait, it could tie these existing programs (players and search utilities) together in a new and useful way, with a minimum of new code required.

The Assignment

For this assignment, we'll implement a simple video player front-end program we'll call mvp (for "My Video Player").

Users will run mvp in one of three modes: (1) interactive, (2) automatic, and (3) testing.

For interactive, a user will type

    mvp -i <videoname>

When started in interactive mode, mvp will present a numbered list of known video players (showing their complete path name) to the user and allow the user to select one of them by number for playing the video file.

In this mode, mvp should also present the user with option 0 (zero) which is the option of selecting another video player not known to mvp for playing the video. (In other words, mvp should have an option listed as "other" and numbered 0 such that, if the user selects 0, mvp should ask for the name for the video player to use.) If the user gives only the name of the video player (rather than its pathname), mvp should search the user's path for this player. Note that only the first video player in the path should be used.

Once the user has selected the video player, mvp should verify that the selected player exists on the system. If it does, mvp should exec the selected player on the given video. If it doesn't, mvp should present an appropriate error message to the user.

For automatic, a user will type

    mvp -a <videoname>

    mvp <videoname>

When started in automatic mode, mvp will run through its known video players, trying each one in turn, until it finds one that successfully plays the video file given by the user. For each player that fails to play a given video, mvp will give an appropriate error message that includes the pathname of the player that failed. When a player successfully plays the video, mvp will give an appropriate success message that includes the pathname of the player that succeeded.

For testing, a user will type

    mvp -t <videoname>

When started in testing mode, mvp will act the same as it does in automatic mode (including the displaying of error messages), with the exception that it will continue to try subsequent video players after successes as well as after failures.

As discussed above, mvp could "know" about these players from several sources, including having pathnames hard coded within it, reading environment variables, searching the user's path for known players, searching the file system for known players, getting pathname and/or player name information directly from the user, or some combination of of these. We will use all of these methods except hard coding and searching the file system. (In your write-up, explain why hard coding is not a good option. We won't search the file system since to integrate this with your code would require file system or IPC knowledge that we have not yet covered in the course.) Getting the pathname and/or player name information directly from the user has been covered above under interactive mode. Below, the environment variables and path searching are described.

When started, mvp should check for environment variables named VPP<num> where <num> is a positive integer (e.g,. VPP1, VPP2, VPP3). These are the full pathnames of video players that mvp should attempt to use.

Similarly, mvp should check for environment variables named VP<num> where <num> is a positive integer (e.g,. VP1, VP2, VP3). The difference between VP<num> and VPP<num> is that with VP<num>, no path information will be given. In this case, mvp should search the user's path for video players with the names given in these variables. Note that only the first video player in the path should be used.

(Note that environment variables VPP<num> and VP<num> are ones I just invented for this assignment. For that reason, you cannot expect these to be already set on your system. To use them, you'll want to set them in your shell, either manually or by including them in your shell initialization scripts, before trying to run mvp.)

Searching the user's path could be done using POSIX system calls within mvp. However, because this assignment is to teach you about using fork, exec, and wait to make use of existing programs on the system, you should using existing utility programs, such as which.

Notes on this Assignment

Some parts of the assignment above are vague or incomplete. This is intentional. This is to give you experience with the way software development is done in "the real world" (industry, academia outside the classroom, government labs, etc.). Often you will get problem descriptions that are vague or incomplete, even if they seem concrete and complete initially.

You should read through the assignment carefully, look for ambiguities or cases not covered, then ask about them, either in office hours or through email, as soon as you can. (Recall that those people who come to office hours get priority over those who call during office hours who, in turn, get priority over those who send email.) If you wait until the last minute to ask about ambiguities or missing cases, you may not get an answer before your project is due. If you don't get an answer in time (or at all, if you don't ask), then you will have to guess how to handle certain situations. If you guess wrong, you will lose points.

To run other programs from within mvp, you must use fork, exec, and (if appropriate) wait or waitpid, not system.

It is up to you to try to find video players available on the CSN lab machines to use with mvp. I suggest using utility programs such as man, apropos, info, locate, and find, as well as doing web searches to learn more about the video players available under Linux. Please note that not all video players will give useful exit values by default and some may not give useful exit values at all. Be sure to discuss what you have found in this regard in your write-up. For this assignment you should find a minimum of two video players that do return useful exit values.

It is also up to you to try to find video files in various formats that you can use for testing of mvp.

What to Turn In

You will turn in both a hard copy and an electronic copy of your assignment. Please follow the instructions on how to send electronic copies. Do not send them to my email address.

Both the hard copy and the electronic copy will contain a write-up and all source code you used in this project. The electronic copy will also contain the executable version of your code. The electronic copy of your write-up should not be in a proprietary format (such as MS Word); it should be either in plain ASCII text or in a portable format (such as Postscript or PDF). Your source code should be in a single file called mvp.c (for C code) or mvp.cxx (for C++ code) and your executable code should be called mvp.

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

Your write-up will include 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 explanation, which are encouraged and may take up any amount of space. (This explanation does not remove the requirement that your code be well commented.)

Your write-up will also include a testing script for your program including (1) the commands used to compile your program and (2) an example run for your program showing its input and output while running through at least one example of each of the three run modes (-i, -a, and -t). For the example run, please use videos freely available from the web and include URLs for them so that the TA may download them and test them with your code.

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 write-up, including the names and student ID numbers of everyone involved.

Each group member is required to contribute equally to each project, as far as is possible. You 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, both your write-up and the comments in your code must clearly indicate this division of labor.