CS61B FAQ (Frequently Asked Questions)

Q: What is the 'standard input'? How is it used? How can I read a file with the standard input?

A: "The standard input" in Unix refers to a particular stream of input that is available to a program. When a program is started by typing a command to the shell (i.e., at a terminal), the standard input is generally taken from what is subsequently typed at the keyboard. The user can direct otherwise, using input redirection, as in 

   % java Foo < mytests
which behaves as if the contents of file mytests were typed to the command 
   % java Foo
or using a pipe, as in 
   % command1 | command2
which behaves as if the standard output [See "What is the standard output?"] from command1 were typed as the standard input of command2.

From inside a program, the standard input is simply a pretty-much ordinary file or stream (depending on programming language). In Java, for example, it appears as a java.io.InputStream called System.in. Reading from System.in reads the standard input.

Q: What is the 'end of file'? Is it a character? How do I get an end-of-file at my terminal?

A: The term is a bit confusing, since it suggests that an end-of-file is a thing. On our systems, the term refers simply to a condition in which there are no more bytes in a particular input stream. When reading an ordinary file, the system will indicate an end-of-file condition in a variety of ways when you attempt to read a byte after having already read all bytes of the file. For example, a number of Java classes for reading files and other streams of data have a read() member function that returns either the next unsigned byte (that is, an 8-bit quantity in the range 0-255) or char (a 16-bit quantity in the range 0-65535) OR returns -1 (which is impossible as an unsigned 8 or 16-bit quantity) to indicate that end-of-file has been reached and there is no more input.

When entering data at a terminal (that is, when your program is using the terminal as its standard input), various systems have various conventions for terminating the input. The Unix shells use Control-D, and Emacs uses the two-character combination Control-C Control-D. In NEITHER case does the program see a Control-D character ('\004' == 4); it's not considered part of the input. There is no Control-D character at the ends of files in Unix; they just end. The Control-D character or whatever is simply a signal to the shell that terminal input has ended.

PRACTICAL NOTE: By the way, while developing and testing a program, entering input from the terminal is usually a bad idea, since it is hard to repeat tests exactly. I suggest always putting input into files and using input redirection (the "<" character) to use those file as standard input. If you are writing an interactive program, of course, you have to do some hand testing to make sure that prompts happen at the right place, etc., but most programs accept input from the standard input in the interest of completeness and flexibility (specifically, for use with "|") rather than for hand input.

Q: What is the 'standard output'? How is it used? How can I write a file with the standard output?

A: "The standard output" in Unix refers to a particular stream of output to which a program may write. When a program is started by typing a command to the shell (i.e., at a terminal), the standard output generally goes to the user's terminal (the screen). The user can direct otherwise, using output redirection, as in 

   % java Foo > fooresults
-- which takes what would have been printed at the terminal by 
   % java Foo
and instead stores it into the file 'fooresults', erasing its previous contents -- or using a pipe, as in 
   % command1 | command2
which behaves as if the standard output from command1 were typed as the standard input of command2.

From inside a program, the standard output is simply a pretty-much ordinary file or stream (depending on programming language). In Java, for example, it appears as a java.io.PrintStream called System.out. Writing to System.out writes to the standard output.

Q: How do I get StreamTokenizer to NOT parse numbers, and return numerals like "125" as words (Strings)?

A: This is a dash obscure, but you actually CAN figure it out from the full documentation of StreamTokenizer. The documentation tells you that

Thus, 

    str.resetSyntax ();
    str.wordChars ('0', '9')
makes all digits into word characters that are not parsed as numbers.

Q: What does try/catch do?

A: The try/catch has three phases.

The try clause:
Execution of the things in a try block are as normal, unless an exception is thrown from anything in that block or thrown (and not caught) by some function that the block calls. If such an exception is thrown, execution jumps to the catch clauses.
The catch clause:
Each catch claus is checked in order to see if it can catch the exception. (checks if the exception thrown is a subclass of the type of the parameter to the catch clause) If a clause catches the exception then the statements in the block following the catch are run. Only the first matching clause catches the exception
The finally clause:
The optional finally clause states things that must be done regardless of how the try block ends (whether normally, by exception, by return, by break, by catch clause, etc.). This is useful for closing up files or streams that were left open by the function that threw the exception. If the finally clause completes normally (without throwing an exception, breaking, etc.), then whatever caused entry into the finally clause takes effect. So, if there was an exception, Java propogates the exception---throws it again, essentially. If the exception was caught, then execution continues after the try/catch/finally statements.

Q: How do I test my program?

A: Create within one of your classes a method called main such as this: 

    public static void main(String args[]) {
       ...
    }
Java will run this method when you type java , so put any code you want to run into that main.

Q: What is gmake (or make) for?

A: It follows the directions in a file called Makefile (or one of several alternative names) that tell how to perform certain tasks: typically compiling ("rebuilding") your program, but the mechanism is very general. See our makeshift makefile tutorial, and our Tool Documents link for more information.

Q: What does System.out.flush() do?

A: System.out.println(), like many file objects, does not output characters as soon as it receives them. Rather, for performance reasons, it buffers the output sent to it -- that is, it holds it until it has accumulated "enough" and then sends a whole clump of characters. Therefore, if you are debugging your program, and you have a print statement you're moving around, trying to find where the bug is... you may be misled, because the program may die and not print something even though the print statement was executed. The data was sent to the buffer, but because the program exited abnormally, the program never got around to emptying the buffer. When done with a file, the close() operation will empty the buffer. In general, output to System.out is flushed at ends of lines. Other than that, calling System.out.flush() will force out the contents of any buffer. There aren't really many occasions where you really need it, but it is useful for seeing partial lines as they are produced.

Q:How do I indent my files?

A: In Emacs, first select what you want to indent, then indent using the command M-x indent-region (that is "meta-x" or ESC x) or M-C-\ (that is, "meta-control-backslash" or ESC CTRL \). To select the whole buffer, use C-x h. To select a smaller region, you can use the usual click-and-drag.

Q:How do I run a test under "make" that is supposed to have errors?

A: The problem here is that if your make file runs your program on data that is supposed to cause the program to exit with an error code, make by default treats this as an error and stops. If it is a matter of a command like this: 


test:
         java solve BAD_INPUT
then you can simply precede the line with a minus sign: 

test:
         -java solve BAD_INPUT
which says "don't stop on error."

However, in our makefiles, there are more elaborate tests where this doesn't work. If you have set up make test to run command files through the shell, then you can alter those command files. For example, if your make file does something like this 


test
        ... 
        . test1   # Means "run the script in file test1"
and test1 contains the test in the first example above, then you can simply add another line to get a good exit code: 

java solve BAD_INPUT
true
or test that the exit code from your program really is bad, as it is supposed to be: 

java solve BAD_INPUT
test $? -ne 0      # Exits normally only if the exit code from 
                   # java solve was not 0.

Q:How do I read the results of make test, particularly the stuff that comes out of "diff"?

A: Our "make test" commands tend to run a command on your program and then run the "diff" utility to compare the output with some standard file. Here are some examples: Contents of file test1: 

blah blah
blahextralinehere
Contents of file test2: 
blah blah
Result of running diff: 
pulsar> diff test1 test2
2d1
< blahextralinehere

Explanation: The message may sound mysterious, but it means "I was on line 2 of the first file, and on line 1 on the second file, when I found that I would need to delete lines on the left file to make them the same."

Here's another example:

Contents of file test1: 

Joe lives in the blue house.
Joe is the cowhand.

Contents of file test2: 

Joe lives in the blue house.
Joe is the sheepherder.

Running diff: 

pulsar> diff test1 test2
2c2
< Joe is the cowhand.
---
> Joe is the sheepherder.

Explanation: The format is pretty much the same here. The "2c2" means "I was on line 2 of the left, and line 2 of the right." The "c" means I would need to change this line to this other line in order to make the files the same. Contents of test1: 

Joe lives in the blue house.
Contents of test2: 
Joe lives in the blue house.
Joe does not live in the crazy house.
Result of diff: 
pulsar> diff test1 test2
1a2
> Joe does not live in the crazy house.
Explanation: The only thing new here is the "a", which stands for add. You'd need to add that line to the first file in order to make them the same.

One last example:

Contents of test1: 

Joe lives in the blue house.
Joe is not the caffeine_addict.
Contents of test2: 
Joe lives in the blue house.
Joe is not the caffeine_addict.
Results of diff: 
pulsar>diff test1 test2
3d2
<
Explanation: The files look identical! Why is diff complaining? Well, according to the output, it says there's a third line on the first file, and sure enough, there is. It's a blank newline, and diff sees it. Often times this one trips people up.

Q: How can I download the ucb.io packages?

A: The UCB classes are in the JAR archive file ~cs61b/lib/classes/ucb.jar. See the reader chapter on compilation, which contains information on JAR files and classpaths.