UNIX – Lesson 009 – Standard file descriptors, Input Redirection, Output Redirection and I/O Redirection
Standard file descriptors
Whenever any program is executed (i.e. when the user types a command) the program has 3 important files to work with. They are standard input (stdin), standard output(stdout), and standard error(stderr).
At the end, each shell open three kind of files:
stdin, stdout and stderr
- stdin = standard input file, from which shell reads its input (generally the KEYBOARD)
- stdout = standard output file, where shell writes its normal output (generally DISPLAY/SCREEN)
- stderr = standard error file, where shell writes its error messages (generally DISPLAY/SCREEN)
Any command that reads its input from stdin can have its input redirected from another file.
This is called input redirection (<)
$ mail firstname.lastname@example.org < input.txt
It sends an email to email@example.com with the content of input.txt file as body of email.
Any command that produces an output to stdout (that normally goes to the terminal) can have its output redirected to another file instead.
This is the output redirection > or >>
Note that > and >> works in different way in the two examples below.
- In the first one, if the output file doesn’t exist it’s created, else it’s overwritten.
- In the second (>>), if the file doesn’t exist it’s created, else the output is
appended to the existing file.
$ ls -al > list_file.txt
It creates a file named “list_file.txt” and write the directory listing in that file.
$ date > date.out
It creates or overwrites a files called date.out
$ date >> date.out
It appends the output in date.out file
This is a very popular feature that many Unix users are happy to learn. In case you have worked with Unix for some time, you must have realised that for a lot of commands you type you get a lot of error messages. And you are not really bothered about those error messages. For example whenever I perform a search for a file, I always get a lot of permission denied error messages. There may be ways to fix those things. But the simplest way is to redirect the error messages elsewhere so that it doesn’t bother me. In my case I know that errors I get while searching for files would be of no use to me.
Here is a way to redirect the error messages
$ my_program 2>errorsfile
This above command would execute a program named “my_program” and whatever errors are generated while executing that program would all be added to a file named “errorsfile” rather than be displayed on the screen. Remember that 2 is the error output file descriptor. Thus “2>” means redirect the error output.
$ my_program 2>>all_errors_till_now
The above command would be useful in case you have been saving all the error messages for some later use. This time the error messages would append to the file rather than create a new file.
You might realize that in the above case since I wasn’t interested in the error messages generated by the program I redirected the output to a file. But since those error messages don’t interest me I would have to go and delete that file created every time I run that command. Else I would have several such files created all over whenever I redirect my unwanted error output. An excellent way around is shown below
$ find / -name s*.jpg 2>/dev/null
What’s /dev/null ?
That something like a black hole. Whatever is sent to the “/dev/null” never returns. It simple disappears.
There is a way for redirect both standard output and standard error
- SH syntax:
> file_name 2>&1 redirect both stdout and stderr to file_name
>> file_name 2>&1 append both stdout and stderr to file_name
- CSH syntax:
>& file_name redirect stdout and stderr to file_name
>>& file_name append stdout and stderr to file_name