Run Better

This assignment involves making three changes the the posted runner example. You should be able to solve it in whatever environment you used for the first assignment: Unix, Linux (including VMs or WSL), or Mac should work fine. Start by grabbing the program and compiling it on your platform.

To get started, download this starting code. Unpack it into its own directory in the Unixy environment where asst1 can compile. Go there on the command line, and say make to build two executable files, the original runner and lbrun which we'll talk about later. (You may need to say instead gmake on Mac, but I don't think it will matter.) If you want to build the files using an IDE, that's fine, but it's your problem to make it work. You always have the option use it to edit, and build from the command line. Then, make the three improvements.

Error Reporting

Improve the reporting of errors by the program.

1. Unix system calls generally return negative values (or sometimes NULL) to indicate failure. You should capture these, report the errors, and generally exit. Some very useful tools are errno and strerror. For instance, the existing fork call should become something like this:
   pid_t kidpid = fork(); if(kidpid < 0) { cerr << "Fork failed: " << strerror(errno) << endl; exit(10); }
   This will whine and exit if the call fails. Afterwards, test the variable kidpid to see if you are the child or parent. (Don't call fork again). You can use a similar pattern to improve the existing wait call, and use strerror() to report the reason for an exec failure.

2. The wait call can also return the reason why the child process terminated. It does this through its parameter. So your wait call will look something like

   int status; kidpid = wait(&status);
   Use the return value to tell if the wait succeeded. If it did, then status will tell you what happened to the child process. Read the wait documentation for details. If the process was signaled, that means it crashed. If it exited, that means it didn't, though it also reports a status code to say if something went wrong. Zero is normal termination, nonzero is an error. Determine if the process exited or crashed. If exited, say if it exited normally or gave a code and print the code. For crashed, extract the signal number which gives the cause, and use the strsignal utility to get a nice message for printing it.

   The wait manual documents several tests that you can apply to the status after wait returns to see what happened. If instance, say if(WIFEXITED(status) to see if the process exited, rather than crashed. If so, the WEXITSTATUS(status) will tell you code it exited with.

   extrunner$ ./runner Your command? /bin/ls -l missing.txt ls: cannot access 'missing.txt': No such file or directory Abnormal exit code 2 extrunner$ ./runner Your command? /bin/ls -l runner.cpp -rw-rw-r--. 1 bennet bennet 1302 Sep 19 14:57 runner.cpp Normal exit extrunner$ ./runner Your command? boomer stk I'm going down!!!!! Killed: Segmentation fault

Parse An Input Line

The current runner asks separately for a command and a parameter, and can have only one. A command interpreter generally takes a line of input (a command) and breaks it up into pieces to provide the parameters for the command. You should do this. To simplify the task, you are given a class LineBreaker2. (Yes, there is an older version.) This object takes a C++ string and breaks it up into words and stores them as plain C strings in its peculiar way. There are three files, the header, linebreaker2.h, the implementation, linebreaker2.cpp, and a test driver lbrun.cpp. Read the comments in linebreaker2.h to see what the methods do, look at lbrun.cpp to see them used. Run lbrun and follow your nose to see some execution examples.

When you exec the program, you should use the execv form of exec. This takes two parameters, the full file name to execute, and an array of strings which are the parameters for the execution. This is an array of plain C strings, rather than C++ ones. By design, LineBreaker2 provides exactly what is needed. Subscript at 0 for the file name, and send the whole C array as the second parameter. This effectively sends the file name twice, but that is what exec expects.

Providing Input