Description
1 Introduction
7 In this assignment you will implement a realistic shell interpreter (RSI), interacting with the operat8 ing system using system calls. The RSI will be very similar to the Linux shell bash: it will support
9 foreground execution of programs, the ability to change directories, and background execution.
10 You should implement your solution in C. Your work will be tested on machines in ECS 242
11 (the Linux drop-in lab) or on linux.csc.uvic.ca.
12
13 Note: linux.csc.uvic.ca is a particular machine at the UVic Department of Computer Sci14 ence. It does not mean “any Linux machine” at UVic. Even more importantly, it does not mean any
15 “Unix-like” machine, such as a Mac OS X machine—many students have developed their programs
16 for their Mac OS X laptops only to find that their code works differently on linux.csc.uvic.ca
17 resulting in a substantial loss of marks.
18 You can remote access linux.csc.uvic.ca by ssh username@linux.csc.uvic.ca. SSH clients
19 are available for a wide variety of operating systems including Linux, Mac OS and Windows.
20 Be sure to study the man pages for the various systems calls and functions suggested in this
21 assignment. The system calls are in Section 2 of the man pages, so you should type (for example):
22 $ man 2 waitpid
23 2 Schedule
24 In order to help you finish this programming assignment on time successfully, the schedule of this
25 assignment has been synchronized with both the lectures and the tutorials. There are three tutorials
26 arranged during the course of this assignment.
Date Tutorial Milestones
May 18 P1 spec go-through, design hints, system calls design and code skeleton
May 25 more on system programming and testing alpha code done
June 1 final testing and last-minute help final deliverable
1
27 3 Requirements
28 3.1 Basic Execution (30%)
29 Your RSI shell shows the prompt
30 linux.csc.uvic.ca:/home/user$ ./rsi
31 RSI: /home/user >
32 for user input. The prompt includes the current directory name in absolute path, e.g., /home/user.
33 Using fork() and execvp(), implement the ability for the user to execute arbitrary commands
34 using your shell program. For example, if the user types:
35 RSI: /home/user > ls -l /usr/bin
36 your shell should run the ls program with the parameters -l and /usr/bin — which should list
37 the contents of the /usr/bin directory on the screen.
38 Another example, RSI: /home/user > mkdir test will create a directory with the name test
39 under /home/user, i.e., a directory /home/user/test is actually created in the host file system.
40
41 Note: The example above uses 2 arguments. We will, however, test your RSI shell by invoking
42 programs that take more than 2 arguments.
43 A well-written shell should support as many arguments as given on the command line.
44 3.2 Changing Directories (30%)
45 Using the functions getcwd() and chdir(), add functionality so that users can:
46 • change the current working directory using the command cd
47 The cd command should take exactly one argument — the name of the directory to change into.
48 The special argument .. indicates that the current directory should “move up” by one directory.
49 That is, if the current directory is /home/user/subdir and the user types:
50 RSI: /home/user/subdir > cd ..
51 the current working directory will become /home/user.
52 The special argument ∼ indicates the home directory of the current user. If cd is used without
53 any argument, it is equivalent to cd ∼, i.e., returning to the home directory, e.g., /home/user.
54
55 Note: There is no such a program called cd in the system that you can run directly (as you did
56 with ls) and change the current directory of the calling program, even if you created one. You
57 need to use the function chdir().
58 3.3 Background Execution and Process Management (30%)
59 Many shells allow programs to be started in the background—that is, the program is running, but
60 the shell continues to accept input from the user.
61 You will implement a simplified version of background execution that supports executing pro62 cesses in the background. The maximum number of background processes is not limited.
2
63 If the user types: cat foo.txt & or nohup cat foo.txt &, your RSI shell will start the com64 mand cat with the argument foo.txt in the background. That is, the program will execute and
65 the RSI shell will also continue to execute and give the prompt to accept more commands. Note
66 that if you run a program in the background with &, the background process will be automatically
67 terminated when you log out. To avoid this, use nohup to run a command immune to hangups.
68 The command ps will have the RSI shell to report a list of all the processes currently running.
69 Note that ps has different options to display various information regarding the processes. Check
70 man ps for details.
71 Related to process management, in your RSI shell:
72 1. The command ps -e display all processes using standard syntax.
73 2. The command kill pid will send the TERM signal to the job with process ID pid to terminate
74 that job.
75 See the man page for the kill() system call for details.
76 Your RSI shell must indicate to the user when background jobs have terminated. Read the man
77 page for the waitpid() system call. You are suggested to use the WNOHANG option.
78 If the user types an unrecognized command supported by neither internal nor external com79 mands, an error message is given by the RSI, e.g.,
80 RSI: /home/user > ttest
81 RSI: ttest: command not found
82 4 Odds and Ends
83 4.1 Compilation
84 You’ve been provided with a Makefile that builds the sample code (in p1s.tar.gz). It takes care
85 of linking-in the GNU readline library for you. The sample code shows you how to use readline()
86 to get input from the user, only if you choose to use the readline library.
87 4.2 Submission
88 Submit a tar.gz archive named p1.tar.gz of your assignment to connex dropbox.
89 You can create a tar.gz archive of the current directory by typing:
90 tar zcvf p1.tar.gz *
91 Please do not submit .o files or executable files (a.out) files. Erase them before creating the
92 archive.
93 4.3 Helper Programs
94 4.3.1 inf.c
95 This program takes two parameters:
96 tag: a single word which is printed repeatedly
3
97 interval: the interval, in seconds, between two printings of the tag
98 The purpose of this program is to help you with debugging background processes. It acts a trivial
99 background process, whose presence can be “felt” since it prints a tag (specified by you) every few
100 seconds (as specified by you). This program takes a tag so that even when multiple instances of it
101 are executing, you can tell the difference between each instance.
102 4.3.2 args.c
103 This is a very trivial program which prints out a list of all arguments passed to it.
104 This program is provided so that you can verify that your RSI shell passes all arguments supplied
105 on the command line—often, people have off-by-1 errors in their code and pass one argument less.
106 4.4 Code Quality 10%
107 We cannot specify completely the coding style that we would like to see but it includes the following:
108 1. Proper decomposition of a program into subroutines (and multiple source code files when
109 necessary)—A 500 line program as a single routine won’t suffice.
110 2. Comment—judiciously, but not profusely. Comments also serve to help a marker, in addition
111 to yourself. To further elaborate:
112 (a) Your favorite quote from Star Wars or Douglas Adams’ Hitch-hiker’s Guide to the Galaxy
113 does not count as comments. In fact, they simply count as anti-comments, and will result
114 in a loss of marks.
115 (b) Comment your code in English. It is the official language of this university.
116 3. Proper variable names—leia is not a good variable name, it never was and never will be.
117 4. Small number of global variables, if any. Most programs need a very small number of global
118 variables, if any. (If you have a global variable named temp, think again.)
119 5. The return values from all system calls and function calls listed in the assignment
120 specification should be checked and all values should be dealt with appropriately.
121 If you are in doubt about how to write good C code, you can easily find many C style guides on
122 the ’Net. The Indian Hill Style Guide is an excellent short style guide.
123 4.5 Plagiarism
124 This assignment is to be done individually. You are encouraged to discuss the design of your solution
125 with your classmates, but each person must implement their own assignment.
126 Your markers may submit the code to an automated plagiarism detection program.
127 We add archived solutions from previous semesters (a few years worth) to the plagia128 rism detector, in order to catch “recycled” solutions.
129
130 The End
4
