Assignment 3, due Feb. 2

Part of the homework for CS:3620, Spring 2018
by Douglas W. Jones
THE UNIVERSITY OF IOWA Department of Computer Science

Background: If you run mush, you'll find that it works for commands like /bin/echo and /bin/vi but it fails when you try to compile a program. Here's a transcript of what happens:
```
>/bin/cc -o mush mush.c
collect2: fatal error: cannot find 'ld'
compilation terminated.
```
The problem is, /bin/cc relies on a search path that's part of the default environment.
A problem: Fix it. Everything you need to know to fix this is in the notes for Jan. 26. Only two lines of code are involved, so give your fix in the form of notes that explain what lines of code to add, delete or change. (1.0 points)
First, we need access to the environment passed by the caller. One way to do it is with a global declaration can be put anywhere at the outermost nesting level before launch(), but it's natural to put it up with the other global variable declarations, for example, right after the declaration for argv. Here is the declaration:
```
extern char **environ;
```
Second, we need to pass on the environment in the call to execve() inside launch(), so the NULL parameter needs to be replaced, giving a result that reads as follows:
```
execve( argv[0], argv, environ );
```
Background: The notes for Jan. 29 describe the relationship between character-sequential and line-sequential input. Inside an operating system that provides both, it is possible that ...
- ... the character-sequential input service first reads a line using the line-sequential service and then picks off successive characters, or
- ... the line-sequential service uses the character-sequential service to construct lines from characters, or
- ... neither of the above, the two services are independent of each other and both work in terms of some lower level primitives not exposed through the C library.
The getcommand() function in our minimal shell mush only uses getchar() to read lines. It could have used fgets(command,100,stdin) to read an entire line of text instead of using a loop of repeated calls to getchar().
A problem: Experiment with replacing the loop of repeated getchar() calls in mush with a single call to fgets() for reading the input command line. Study its behavior, with the goal of trying to figure out how getchar() and fgets() are related (that is, which of the three alternatives above describes their relationship.)
Identify the relationship and support your conclusion with descriptions of the observed behaviors that convince you of that relationship. (1.0 points)

Nothing in the code distributed for getcommand() handles backspaces, yet when I type part of a line and then type the right backspace character to make a correction, the correction works. This implies that some lower level piece of code is collecting an entire line before it releases it to my application. In effect, getc() is sitting on top of something like fgets().
There is one complexity which made these experiments difficult. Above, I said "the right backspace character." Backspace on my keyboard sends the control-H character, while delete on my keyboard sends something else, a long escape sequence that prints as "^[[3~". The "right backspace character", at least for me, turned out to be set to control-? -- not exactly an obvious choice. Last time I tried this experiment, the default was control-H.
Background: The linux linker is called ld. By default, the cc command finishes the job of compiling by using ld to link the compiled program with the C standard library. The error discussed in the preface to 1 appears to be the result of cc using an environment variable in order to find where to look for ld.
We have already discussed the standard shell's search path, which it gets from the environment variable PATH. The following questions are best answered by a bit of judicious googling (lower case, because I use this verb to refer to use of any search engine).
a) Name some of the search paths that the cc command uses that are not involved with linking. (0.5 points)

This is a bit of a research question. I googled and found that cc uses several environment variables to find paths:

CPATH
C_INCLUDE_PATH
tells the compiler where to search for files mentioned in #include directives.

COMPILER_PATH
tells the compiler (or is it the linker) where to look for subprograms.

LIBRARY_PATH
LD_LIBRARY_PATH
tells the linker where the library or libraries are that should be searched for external functions.

The question asked for "some of these"; there are at least 3 categories of paths (I may not have found them all), so students getting one path from each of 2 categories ought to get full credit.

b) Name at least one search path that the cc command is documented as using but is actually used by the linker. (0.5 points)

LIBRARY_PATH (or its synonyms) are clearly used by the linker.