Description
In this assignment you will implement a realistic shell interpreter (RSI), using system calls and
8 interacting with the system. The RSI will be very similar to the Linux shell bash: it will support
9 the foreground execution of programs, ability to change directories, and background execution.
10 You can implement your solution in C or C++. Your work will be tested on u-*.csc.uvic.ca
11 in ECS242. You can remote access the Linux computers in ECS242 Linux Teaching Lab using ssh.
12 For a list of Linux computers (u-*.csc.uvic.ca) in that lab, please check
13 https://www.csc.uvic.ca/labspg/ecs242servers.html
14 Be sure to test your code on u-*.csc.uvic.ca before submission. Many students have devel15 oped their programs for their Mac OS X laptops only to find that their code works differently on
16 u-*.csc.uvic.ca resulting in a substantial loss of marks.
17 Be sure to study the man pages for the various systems calls and functions suggested in this
18 assignment. These functions are in Section 2 of the man pages, so you should type (for example):
19 $ man 2 waitpid
20 2 Schedule
21 In order to help you finish this programming assignment on time successfully, the schedule of this
22 assignment has been synchronized with both the lectures and the tutorials. There are three tutorials
23 arranged during the course of this assignment.
Date Tutorial Milestones
Sept 12 P1 spec go-through, design hints, system calls design and code skeleton
Sept 19∗ more on system programming and testing alpha code done
Sept 26 final testing and last-minute help final deliverable
1
24 3 Requirements
25 3.1 Basic Execution (5 marks)
26 Your shell shows the prompt
27 RSI: /home/user >
28 for user input. The prompt includes the current directory name in absolute path, e.g., /home/user.
29 Using fork() and execvp(), implement the ability for the user to execute arbitrary commands
30 using your shell program. For example, if the user types:
31 RSI: /home/user > ls -l /usr/bin
32 your shell should run the ls program with the parameters -l and /usr/bin—which should list the
33 contents of the /usr/bin directory on the screen.
34
35 Note: The example above uses 2 arguments. We will, however, test your RSI by invoking
36 programs that take more than 2 arguments.
37 A well-written shell should support as many arguments as given on the command line.
38 3.2 Changing Directories (5 marks)
39 Using the functions getcwd() and chdir(), add functionality so that users can:
40 • change the current working directory using the command cd
41 The cd command should take exactly one argument—the name of the directory to change into.
42 The special argument .. indicates that the current directory should “move up” by one directory.
43 That is, if the current directory is /home/user/subdir and the user types:
44 RSI: /home/user/subdir > cd ..
45 the current working directory will become /home/user.
46 The special argument ∼ indicates the home directory of the current user. If cd is used without
47 any argument, it is equivalent to cd ∼, i.e., returning to the home directory, e.g., /home/user.
48
49 Note: There is no such a program called cd in the system that you can run directly (as you did
50 with ls) and change the current directory of the calling program, even if you created one. You
51 have to use the system call chdir().
52 3.3 Background Execution (5 Marks)
53 Many shells allow programs to be started in the background—that is, the program is running, but
54 the shell continues to accept input from the user.
55 You will implement a simplified version of background execution that supports executing pro56 cesses in the background. The maximum number of background processes is not limited.
57 If the user types: bg cat foo.txt, your RSI shell will start the command cat with the argument
58 foo.txt in the background. That is, the program will execute and the RSI shell will also continue
59 to execute and give the prompt to accept more commands.
60 The command bglist will have the RSI shell display a list of all the programs currently executing
61 in the background, e.g.,:
2
62 123: /home/user/a1/foo
63 456: /home/user/a1/foo
64 Total Background jobs: 2
65 In this case, there are 2 background jobs, both running the program foo, the first one with
66 process ID 123 and the second one with 456.
67 Your RSI shell must indicate to the user when background jobs have terminated. Read the man
68 page for the waitpid() system call. You are suggested to use the WNOHANG option.
69 4 Bonus Features
70 Only a simplified shell with limited functionality is required in this assignment. However, students
71 have the option to extend their design and implementation to include more features in a regular
72 shell or a remote shell (e.g., kill/pause/resuming background processes, capturing and redirecting
73 program output, handling many remote clients at the same time, etc).
74 If you want to design and implement a bonus feature, you should contact the course instructor
75 for permission one week before the due date, and clearly indicate the feature in the submission of
76 your code. The credit for correctly implemented bonus features will not exceed 20% of the full
77 marks for this assignment.
78 5 Odds and Ends
79 5.1 Compilation
80 You will be provided with a Makefile that builds the sample code. It takes care of linking-in the
81 GNU readline library for you. The sample code shows you how to use readline() to get input
82 from the user, only if you choose to use readline library.
83 5.2 Submission
84 The submission is done through connex. The tutorial instructor will give the detailed instruction
85 on the submission of this assignment in the tutorial of Sept 26, 2014.
86 5.3 Helper Programs
87 5.3.1 inf.c
88 This program takes two parameters:
89 tag: a single word which is printed repeatedly
90 interval: the interval, in seconds, between two printings of the tag
91 The purpose of this program is to help you with debugging background processes. It acts a trivial
92 background process, whose presence can be “felt” since it prints a tag (specified by you) every few
93 seconds (as specified by you). This program takes a tag so that even when multiple instances of it
94 are executing, you can tell the difference between each instance.
95 This program considerably simplifies the programming of the part of your RSI shell which deals
96 with re-starting, stopping, and killing programs.
3
97 5.3.2 args.c
98 This is a very trivial program which prints out a list of all arguments passed to it.
99 This program is provided so that you can verify that your shell passes all arguments supplied on
100 the command line — Often, people have off-by-1 errors in their code and pass one argument less.
101 5.4 Code Quality
102 We cannot specify completely the coding style that we would like to see but it includes the following:
103 1. Proper decomposition of a program into subroutines — A 500 line program as a single routine
104 won’t suffice.
105 2. Comment—judiciously, but not profusely. Comments serve to help a marker. To further
106 elaborate:
107 (a) Your favorite quote from Star Wars or Douglas Adams’ Hitch-hiker’s Guide to the Galaxy
108 does not count as comments. In fact, they simply count as anti-comments, and will result
109 in a loss of marks.
110 (b) Comment your code in English. It is the official language of this university.
111 3. Proper variable names—leia is not a good variable name, it never was and never will be.
112 4. Small number of global variables, if any. Most programs need a very small number of global
113 variables, if any. (If you have a global variable named temp, think again.)
114 5. The return values from all system calls listed in the assignment specification
115 should be checked and all values should be dealt with appropriately.
116 If you are in doubt about how to write good C code, you can easily find many C style guides on the Net.
117 The Indian Hill Style Guide is an excellent short style guide.
118 5.5 Plagiarism
119 This assignment is to be done individually. You are encouraged to discuss the design of your solution
120 with your classmates, but each person must implement their own assignment.
121 Your markers will submit the code to an automated plagiarism detection program.
122 We add archived solutions from previous semesters (a few years worth) to the plagia123 rism detector, in order to catch “recycled” solutions.
124
125 The End
4
