Be sure you have read Chapter 1.
Answer the following questions. You may write out your answers by hand or using a word processor or other program, but please submit hard copy, either in class or in my mailbox in the department office.
(Hint: In general, user programs should not be allowed to execute instructions that might interfere with the operating system's control of the machine. The most reasonable way to keep them from doing so is to allow such instructions only in supervisor mode. Notice that this question refers to machine-level instructions, not necessarily functionality. An operating system could make the functionality of some of these instructions available to user programs by wrapping them in system calls, and possibly requiring user programs to supply a password to (successfully) execute these calls.)
strace -o OUT ls -l
Your mission for this problem is to run strace for a command of your choice, capture the output, and then describe what some of it means. Specifically, I want you to pick at least four lines of the output using different system calls and briefly explain each of these lines, describing in general terms what the system call is supposed to do and what the parameters and return value mean. (So, you will turn in a printout of (part of) the output of strace with your homework. You might want to mark it up with numbers and then refer to these numbers in your explanation.)
The man page for strace explains the general format of the output. To find out what the individual system calls do, you will need to read their man pages. Some of these are easy to find -- e.g., the first call is usually to execve, and man execve will tell you about it. Some are a little harder to track down -- e.g., man open produces information about an open command rather than a system call. man -k open produces a list of all man pages whose one-line descriptions include ``open'', and from this list one can perhaps guess that to look at the desired man page you need the command man 2 open.
As an example of what I have in mind, here is a line from a trace of the command ls /users/cs4320 with commentary. (You should choose system calls other than execve.)
execve("/bin/ls", ["ls", "/users/cs4320"], [/* 78 vars */]) = 0
The call to execve creates a new process to run the command. Parameters are the command to execute, the arguments to pass to it, and an array of environment variables (82 of them, apparently!). The return value of 0 probably doesn't mean anything, since the man page for execve says that the function doesn't return if the call is successful.
Do the following programming problems. You will end up with at least one code file per problem. Submit your program source (and any other needed files) by sending mail to bmassing@cs.trinity.edu, with each file as an attachment. Please use a subject line that mentions the course number and the assignment (e.g., ``csci 3323 homework 1''). You can develop your programs on any system that provides the needed functionality, but I will test them on one of the department's Linux machines, so you should probably make sure they work in that environment before turning them in.
$ ./simple-shell-c ? /bin/ls Makefile simple-shell-c strace.out strace.out.3 myecho.c simple-shell-c.c strace.out.1 strace.out.4 sample.out simple-shell-cpp.cpp strace.out.2 withpid.c ? /bin/ls -l total 92 lrwxrwxrwx 1 bmassing bmassing 51 Sep 6 11:06 Makefile -> /users/bmassing/Home/Makefile/Makefile.c.cpp.simple -rw------- 1 bmassing bmassing 173 Sep 13 2006 myecho.c -rw------- 1 bmassing bmassing 0 Sep 6 11:16 sample.out -rwx------ 1 bmassing bmassing 9764 Sep 6 11:16 simple-shell-c -rw------- 1 bmassing bmassing 5175 Oct 6 2006 simple-shell-c.c -rw------- 1 bmassing bmassing 3984 Oct 6 2006 simple-shell-cpp.cpp -rw------- 1 bmassing bmassing 9385 Aug 29 2012 strace.out -rw------- 1 bmassing bmassing 7657 Sep 14 2009 strace.out.1 -rw------- 1 bmassing bmassing 9547 Sep 30 2010 strace.out.2 -rw------- 1 bmassing bmassing 9390 Aug 31 2011 strace.out.3 -rw------- 1 bmassing bmassing 11241 Sep 6 11:14 strace.out.4 -rw------- 1 bmassing bmassing 5313 Dec 20 2012 withpid.c ? /bin/ls junk /bin/ls: cannot access junk: No such file or directory ? junk Error executing command junk: No such file or directory ? /bin/echo a b c d a b c d ?
You can add more functionality (searching a path for the command, doing more sophisticated parsing of inputs, exiting when the user types ``exit'', etc.). If you do, describe the added functionality in comments at the top of your code. I will give up to 5 extra-credit points for added functionality.
Turning the pseudocode into code mostly involves defining appropriate data structures for the variables in the pseudocode and replacing the type_prompt and read_command functions with appropriate real code. Your first step should probably be to read the man page for execve -- carefully -- to see what arguments it expects, and then figure out what you need to do to turn what the user types in into suitable input to execve. Also recall (or note) that man pages for functions tell you what if any #include directives you need to include in your code.
You will probably find that most of the code you write for this problem will be code to parse the input (accept a line of text and break it into a command and arguments). You can do this using C library functions, with C++ library classes (string and maybe vector), or whatever you prefer. If you use C library functions, you will probably want to read a full line of text using fgets and then use other functions to break up the line into a command name and arguments. If you use the C functions and fixed-size character arrays, make the program fail as gracefully as possible if the user supplies more input than your code has room to accept. If you use the C++ classes, be aware that after parsing the input you may need to convert the result to C-style strings, since that's what execve wants.
You may be tempted to just use the C library function system. Don't. You won't learn what this problem is meant to teach you, and you won't get credit for such a solution.
Last but not least, a C tip: Get in the habit of compiling with the -Wall flag and paying attention to warning messages. Sometimes warning messages really are just warnings you can ignore, but often they are signs of problems you should fix. Also notice that if you compile with -std=c99 you can use C99 features.