Assignment 2, due Feb. 5

Part of the homework for 22C:112, Spring 2010
by Douglas W. Jones
THE UNIVERSITY OF IOWA Department of Computer Science

Always, on every assignment, please write your name legibly as it appears on your University ID and on the class list! All assignments will be due at the start of class on the day indicated (usually a Friday). The only exceptions to this rule will be by advance arrangement unless there is what insurance companies call "an act of God" - something outside your control. Homework must be turned in on paper and in class! Late work may be turned in to the teaching assistant's mailbox, but see the late work policy. Never push late work under someone's door!

  1. Background: Use tools such as od to examine the structure of a Unix object file. Having done so, and having read the text of lecture 7, can you fit the Unix object file format into one of the categories of object code formats discussed there? (0.5 points)

  2. Background: In the example shell program distributed on the web, http://homepage.cs.uiowa.edu/~dwjones/opsys/shell.txt, the function launch_app() is used to launch the application that executes each user command.

    Question: Why must the search path be searched inside the control of the if(fork()) construct? (0.5 points)

  3. Background: Read up on the unix open() kernel call (use the man 2 open shell command to read the manual page).

    a) Propose an alternative approach to testing to see if the desired executable exists, so that the test can be done outside the the if(fork()) construct. (0.5 points)

    b) Discuss the probable computational expense of your alternative as opposed to the version in the toy shell that was distributed to the class. Focus on the question of how many times it would have to read each directory in order to successfully launch an application. (0.5 points)

  4. Background: You can get documentation for the Unix execve() command from the man execve command on any unix system. One problem with the Unix model for launching commands is that the arguments are required to be strings and lose all other type information.

    Consider an alternative, let's call it exect(), where the t suffix means that the argument list entries each have a data type. The argument list would now be a list of ordered pairs. The first element of each pair would be an integer describing a data type, the second element would point to an object of that type. Here is the C declaration for this list:

    struct pair {
    	int type;
    	void * value;
    };
    
    struct pair argv[];
    

    a) What problem would you have with developing an integer encoding of parameter types? (0.2 points)

    b) What problem would you have with writing the code to copy the argument list from the stack of the caller to the stack of the new program launched by exect. (0.2 points)

    c) Why was the argument pointer declared to be of type void *. (0.2 points)

    d) Suppose the integer constant INT_TYPE encodes the type of an integer argument. Write C code to check that argv[1] is an integer, and if it is, assign its value to the variable i. (0.2 points)

    e) Suppose the program that launched an application wanted some hints about what the expected parameter types were? This might be useful to help parse the parameter list in a command language interpreter. If you were implementing the system, where would you put this information? (0.2 points)

Machine Problem 1, due Feb. 15

Modify the example shell mentioned above so that it outputs a prompt to the terminal before each line of input. The prompt should be your name.

For maximum credit, the prompt should be output only if the shell is being run interactively. That is, there should be no prompting if the shell has input from a disk file or if it has output to a disk file. Hint: The C standard library contains a routine isatty() that can be used to test to see if an open file is a terminal device (as opposed to a disk file). The man isatty command will tell you more detail about this.

To submit your work, use the submit command, documented on the web at:
http://www.divms.uiowa.edu/help/msstart/submit.html
Specifically, your source code should be stored in a file named mp1.c and you should submit it in the course c_112 under the submit directory mp1. The submit command is verbose. Striping out all the verbosity, your dialogue with submit will look something like the following:

[jones@serv16 ~]$ submit
 File/directory name: mp1.c
 File/directory name:
Course (22C:016 would be c_016): c_112
Choice: mp1
* File/directory mp1.c has been
* copied to /group/submit/c_112/mp1/mp1.c.jones.

The above has been verified to work, boldface indicates user input, which is always after a colon.