OSU CSE 2421
Required Reading: Pointers on C, Section 15.4.2
J.E.Jones
OSU CSE 2421
In Unix/linux, there are 3 file descriptors that are explicitly defined to represent 3 distinct data streams: stdin (0), stdout (1) and stderr(2).
(These are 3 of the PVC pipes, lol!)
IMPORTANT: By default, in Unix/linux, C programs read input from “standard input (stdin)” (usually, the keyboard) and write output to “standard output (stdout)” (usually, the screen). Unix/linux error messages go to “standard error” (stderr) (also defaults to the screen).
We can change the destination of each of these data streams from the Unix/linux command line using what is called redirection.
You can redirect just the input or just the output or just errors (that is, you do not have to redirect all of them, but you could).
For labs, from time to time it will be convenient to redirect input and allow output to go to standard out (the screen). Obviously, there shouldn’t be any Unix/linux errors to redirect.
J. E. Jones
OSU CSE 2421
We can change the destination of any/all these data streams from the Unix/linux command line using redirection:
◦ < redirects the input, and
◦ > redirects the output,
◦ 2> redirects Unix/linux system errors
NO CODE CHANGES IN OUR PROGRAM!
If we run the same program from the command line and do not use redirection, the program reverts to expecting input from the keyboard and will print output and errors to the screen.
J. E. Jones
OSU CSE 2421
It is important to make sure that the input file has an end of file (EOF) indicator at the end. So, when you are creating/editing your input file, be sure you hit enter at the end of the last line of the file.
Example:
◦ prog1 < prog1.input
This example runs program, prog1, and rather than looking for input from the keyboard, gets its input from the file prog1.input
◦ You used this mechanism within gdb when you did lab1 (i.e., run< lab1.input1)
The file prog1.input is expected to be in the same directory in which prog1 is executing. The program will not look for the file anywhere else unless a full pathname is specified for the input file.
If you redirect stdin, the program will expect all input that it requires (until the program terminates) to come from the specified file (i.e., you can’t put part of the input to the program in a file and then when the data in the file runs out, input the rest of it from the command line).
Any output to stdout or any Unix/linux errors messages to stderr would go to the screen.
J. E. Jones
OSU CSE 2421
Example 1:
% prog1 > output.file
This will run prog1 and write output to output.file
◦ If output.file does not exist, it will create one.
◦ If output.file does exist, any data currently in the file will be erased and only data from the most current run of prog1 will be in the file.
◦ If you do not use a full pathname for the output file, it will only look for the file in the current working directory
Example 2:
% prog1 >> output.file
This will run prog1 and write output to output.file
◦ If output.file does not exist, it will create one.
◦ If output.file does exist, output from the current run of the program will be appended to the end of the file.
◦ If you use this option, be very careful not confuse yourself with respect to what output came from which execution of your program.
Both examples would expect input to come from the keyboard and any Unix/linux errors would be sent to the screen
◦ % echo “—————————–2nd run——————–” >>output.file
◦ %prog1 >> output.file
J. E. Jones
OSU CSE 2421
In most instances, it’s not a good idea to redirect stderr, but from time to time…
Example 1:
% prog1 2> error.file
This will run prog1 and write any Unix/linux error messages to error.file
◦ If error.file does not exist, it will create one.
◦ If error.file does exist, any data currently in the file will be erased and only error messages from the most current run of prog1 will be in the file.
◦ If you do not use a full pathname for the error file, it will look for the file in the current directory
Example 2:
% prog1 2>> error.file
This will run prog1 and write any Unix/linux errors to error.file
◦ If error.file does not exist, it will create one.
◦ If error.file does exist, output from the current run of the program will be appended to the end of the file.
◦ If you use this option, be very careful not confuse yourself with respect to what errors came from which execution of your program. It would be sad to find out that you stayed up all night looking for an error you see in error.file that you fixed before midnight.
Both examples would expect input to come from the keyboard and stdout would be sent to the screen
J. E. Jones
OSU CSE 2421
What if I want to redirect stdout and stderr to the same file?
◦ prog1 > stdout.file 2>&1
◦ 2>&1 means redirect stderr to wherever stdout
currently goes
So, do
◦ prog1 > stdout_stderr.file 2>&1
and
◦ prog1 2>&1 >stdout_stderr.file Do the same thing??
J. E. Jones
OSU CSE 2421
What if I want to redirect stdout and stderr to the same file? ◦ prog1 > stdout.file 2>&1
So,do
◦ Prog1 > stdout_stderr.file 2>&1
and
◦ prog1 2>&1 >stdout_stderr.file Do the same thing??
No! Order matters!
◦ prog1 > /home/user/stdout_stderr.file 2>&1
This will send both stdout and stderr to stdout_stderr.file ◦ prog1 2>&1 > stdout_stderr.file
This will send stdout to stdout_stderr.file, and stderr to what was previously stdout.
When you perform a shell redirection, the left side of the redirection goes to where the right side of the redirection currently goes. Meaning in 2>&1, it sends stderr (2) to wherever stdout (1) currently goes.
But if you, afterwards, redirect stdout somewhere else, stderr doesn’t go with it. It continues to go wherever stdout was previously going. This is why in the first example, both stdout and stderr will go to the same place, but in the second they won’t.
J. E. Jones