cin):
java SomeClass <indata.txt
runs the executable a.out, with the standard input (cin) coming from the file indata.txt (rather than the console).
This is known as input redirection.
As it turns out, Unix associates a program's files and standard streams) with integers (known as file descriptors).
(The standard streams are standard input, standard output, and standard error &mdash.
They are known to C++ programmers as cin, cout, and cerr; and in Unix as standard input,
standard output, and standard error.) In particular it uses the following associations:
| stream | file descriptor |
|---|---|
| standard input / stdin / cin | 0 |
| standard output / stdin / cout | 1 |
| standard error / stderr / cerr | 2 |
file-descriptor>Thus:
java SomeClass 1>output.txt redirects the standard output (cout) to the file output.txt (this is the same as writing
java SomeClass >output.txt, which is simply a shorthand, since cout is redirected so often). Standard error (cerr) goes to the
console.
java SomeClass >output.txt 2>errors.txt redirects thet standard output (cout) to output.txt, while the standard error
(cerr) is redirected to errors.txt.
java SomeClass 2>errors.txt redirects the the standard error (cerr) to errors.txt (output goes to the console).
java SomeClass >out.txt 2>&1;
will redirect BOTH stdout AND stderr to the same file (the >out.txt
redirects standard output to the file out.txt, and the 2>&1; redirects standard error (file descriptor 2) to the same file as file
descriptor 1 (standard output)).
java SomeClass >out.txt 2>out.txt will NOT give you the same result (try it and see if you can figure out why not).