Hello guys welcome back to hacker-heaven..
today we gonna see how the commands output/input and error are displayed by the I/O system..through the terminal..we also learn about commands..
wc(word count),tail,head,cat etc...
Standard Input, Output, And Error
Many of the programs that we have used so far produce output of some kind. This output often consists of two types. First, we have the program's results; that is, the data the program is designed to produce, and second, we have status and error messages that tell us
how the program is getting along. If we look at a command like ls, we can see that it displays its results and its error messages on the screen. Keeping with the Unix theme of “everything is a file,” programs such as ls actually send their results to a special file called standard output (often expressed as stdout) and their
status messages to another file called standard error (stderr). By default, both standard output and standard error are linked to the screen and not saved into a disk file.
thats why every time when you execute your commands its output as well error print out int the screen ..this is beacause it is by default change in your system but their are commands that can change your output and error to be displayed in the file ....
similar to the stdout and stderror ...In addition, many programs take input from a facility called standard input (stdin) which
is, by default, attached to the keyboard.
I/O redirection allows us to change where output goes and where input comes from. Normally,
output goes to the screen and input comes from the keyboard, but with I/O redirection,
we can change that.
Redirecting Standard Output
I/O redirection allows us to redefine where standard output goes. To redirect standard
output to another file instead of the screen, we use the “>” redirection operator followed
by the name of the file. Why would we want to do this? It's often useful to store the output
of a command in a file. For example, we could tell the shell to send the output of the
ls command to the file ls-output.txt instead of the screen:
command :
ls /usr/bin >ls-output.txt
Here, we created a long listing of the /usr/bin directory and sent the results to the file ls-output.txt. Let's examine the redirected output of the command:
If we look at the file with less, we will see that the file
ls-output.txt does indeed contain the results from our ls command:
Now, let's repeat our redirection test, but this time with a twist. We'll change the name of the directory to one that does not exist:
We received an error message. This makes sense since we specified the non-existent directory /bin/usr, but why was the error message displayed on the screen rather than being redirected to the file ls-output.txt? The answer is that the ls program does
not send its error messages to standard output. Instead, like most well-written Unix programs, it sends its error messages to standard error. Since we only redirected standard output and not standard error, the error message was still sent to the screen. We'll see how to redirect standard error in just a minute, but first, let's look at what happened to our output file:
The file now has zero length! This is because, when we redirect output with the “>” redirection operator, the destination file is always rewritten from the beginning. Since our ls
command generated no results and only an error message, the redirection operation started to rewrite the file and then stopped because of the error, resulting in its truncation.
In fact, if we ever need to actually truncate a file (or create a new, empty file) we can use
a trick like this:
Simply using the redirection operator with no command preceding it will truncate an existing
file or create a new, empty file.
So, how can we append redirected output to a file instead of overwriting the file from the
beginning? For that, we use the “>>” redirection operator, like so:
Using the “>>” operator will result in the output being appended to the file. If the file
does not already exist, it is created just as though the “>” operator had been used. Let's
put it to the test:
Redirecting Standard Error
Redirecting standard error lacks the ease of a dedicated redirection operator. To redirect standard error we must refer to its file descriptor. A program can produce output on any
of several numbered file streams. While we have referred to the first three of these file streams as standard input, output and error, the shell references them internally as file descriptors
0, 1 and 2, respectively. The shell provides a notation for redirecting files using the file descriptor number. Since standard error is the same as file descriptor number 2,
we can redirect standard error with this notation:
Redirecting Standard Output And Standard Error To One File
There are cases in which we may wish to capture all of the output of a command to a single file. To do this, we must redirect both standard output and standard error at the same time. There are two ways to do this. First, the traditional way, which works with old versions
of the shell:
command: $ ls -l /bin/usr > ls-output.txt 2>&1
Using this method, we perform two redirections. First we redirect standard output to the
file ls-output.txt and then we redirect file descriptor 2 (standard error) to file descriptor
one (standard output) using the notation 2>&1.
Notice that the order of the redirections is significant.
The redirection of standard error must always occur after redirecting standard output or it doesn't work. In
the example above,
>ls-output.txt 2>&1
redirects standard error to the file ls-output.txt, but if the order is changed to
2>&1 >ls-output.txt
standard error is directed to the screen.
Recent versions of bash provide a second, more streamlined method for performing this In this example,
we use the single notation &> to redirect both standard output and standard
error to the file ls-output.txt. You may also append the standard output and standard error streams to a single file like so:
Disposing Of Unwanted Output
Sometimes “silence is golden,” and we don't want output from a command, we just want to throw it away. This applies particularly to error and status messages. The system provides
a way to do this by redirecting output to a special file called “/dev/null”. This file is a system device called a bit bucket which accepts input and does nothing with it. To suppress error messages from a command, we do this:
command: ls -l /bin/usr 2> /dev/null
Redirecting Standard Input
Up to now, we haven't encountered any commands that make use of standard input (actually we have, but we’ll reveal that surprise a little bit later), so we need to introduce one.
cat – Concatenate Files
The cat command reads one or more files and copies them to standard output like so:
Redirection
cat [file...]
In most cases, you can think of cat as being analogous to the TYPE command in DOS.
You can use it to display files without paging, for example:
ubuntu@ubuntu:$ cat ls-output.txt
will display the contents of the file ls-output.txt. cat is often used to display short
text files. Since cat can accept more than one file as an argument, it can also be used to
join files together. Say we have downloaded a large file that has been split into multiple
parts (multimedia files are often split this way on Usenet), and we want to join them back
together. If the files were named:
movie.mpeg.001 movie.mpeg.002 ... movie.mpeg.099
we could join them back together with this command:
cat movie.mpeg.0* > movie.mpeg
Since wildcards always expand in sorted order, the arguments will be arranged in the correct
order.
This is all well and good, but what does this have to do with standard input? Nothing yet,
but let's try something else. What happens if we enter “cat” with no arguments:
command: cat
Nothing happens, it just sits there like it's hung. It may seem that way, but it's really doing exactly what it's supposed to.If cat is not given any arguments, it reads from standard input and since standard input is, by default, attached to the keyboard, it's waiting for us to type something! Try adding
the following text and pressing Enter:
Next, type a Ctrl-d (i.e., hold down the Ctrl key and press “d”) to tell cat that it has
reached end of file (EOF) on standard input:
In the absence of filename arguments, cat copies standard input to standard output, so we see our line of text repeated. We can use this behavior to create short text files. Let's
say that we wanted to create a file called “lazy_dog.txt” containing the text in our example.
We would do this:
Type the command followed by the text we want in to place in the file. Remember to type Ctrl-d at the end. Using the command line, we have implemented the world's dumbest
word processor! To see our results, we can use cat to copy the file to stdout again:
Now that we know how cat accepts standard input, in addition to filename arguments, let's try redirecting standard input:
Using the “<” redirection operator, we change the source of standard input from the keyboard
to the file lazy_dog.txt. We see that the result is the same as passing a single filename argument. This is not particularly useful compared to passing a filename argument,
but it serves to demonstrate using a file as a source of standard input. Other commands make better use of standard input, as we shall soon see. Before we move on, check out the man page for cat, as it has several interesting options.
Pipelines
The ability of commands to read data from standard input and send to standard output is
utilized by a shell feature called pipelines. Using the pipe operator “|” (vertical bar), the
standard output of one command can be piped into the standard input of another:
command type: command1 | command2
To fully demonstrate this, we are going to need some commands. Remember how we said there was one we already knew that accepts standard input? It's less. We can use less to display, page-by-page, the output of any command that sends its results to standard
output:
The Difference Between > and |
At first glance, it may be hard to understand the redirection performed by the
pipeline operator | versus the redirection operator >. Simply put, the redirection
operator connects a command with a file while the pipeline operator connects the
output of one command with the input of a second command.
command1 > file1
command1 | command2
A lot of people will try the following when they are learning about pipelines, “just
to see what happens.”
command1 > command2
Answer: Sometimes something really bad.
Here is an actual example submitted by a reader who was administering a Linuxbased
server appliance. As the superuser, he did this:
# cd /usr/bin
# ls > less
The first command put him in the directory where most programs are stored and the second command told the shell to overwrite the file less with the output of the ls command. Since the /usr/bin directory already contained a file named “less” (the less program), the second command overwrote the less program
file with the text from ls thus destroying the less program on his system. The lesson here is that the redirection operator silently creates or overwrites files, so you need to treat it with a lot of respect.
Filters/sorting
Pipelines are often used to perform complex operations on data. It is possible to put several commands together into a pipeline. Frequently, the commands used this way are referred
to as filters. Filters take input, change it somehow and then output it. The first one we will try is sort. Imagine we wanted to make a combined list of all of the executable
programs in /bin and /usr/bin, put them in sorted order and view it:
ubuntu@ubuntu:~$ ls /bin /usr/bin | sort | less
Since we specified two directories (/bin and /usr/bin), the output of ls would have consisted of two sorted lists, one for each directory. By including sort in our pipeline,
we changed the data to produce a single, sorted list.
uniq - Report Or Omit Repeated Lines
The uniq command is often used in conjunction with sort. uniq accepts a sorted list of data from either standard input or a single filename argument (see the uniq man page for details) and, by default, removes any duplicates from the list. So, to make sure our list has no duplicates (that is, any programs of the same name that appear in both the /bin and /usr/bin directories) we will add uniq to our pipeline:
ubuntu@ubuntu:~$ ls /bin /usr/bin | sort | uniq | less
In this example, we use uniq to remove any duplicates from the output of the sort command. If we want to see the list of duplicates instead, we add the “-d” option to uniq like so:
ubuntu@ubuntu:~$ ls /bin /usr/bin | sort | uniq -d | less
wc – Print Line, Word, And Byte Counts
The wc (word count) command is used to display the number of lines, words, and bytes contained in files. For example:
ubuntu@ubuntu:~$ wc ls-output.txt
2035 19080 124487 ls-output.txt
In this case it prints out three numbers: lines, words, and bytes contained in ls-output. txt. Like our previous commands, if executed without command line arguments, wc accepts standard input. The “-l” option limits its output to only report lines. Adding it
to a pipeline is a handy way to count things. To see the number of items we have in our
sorted list, we can do this:
ubuntu@ubuntu:~$ ls /bin /usr/bin | sort | uniq | wc -l
2177
ubuntu@ubuntu:~$
grep – Print Lines Matching A Pattern
grep is a powerful program used to find text patterns within files. It's used like this:
grep pattern [file...]
When grep encounters a “pattern” in the file, it prints out the lines containing it. The patterns that grep can match can be very complex, but for now we will concentrate on
simple text matches. We'll cover the advanced patterns, called regular expressions in a
later article. Let's say we wanted to find all the files in our list of programs that had the word “zip” embedded in the name. Such a search might give us an idea of some of the programs on
our system that had something to do with file compression. We would do this:
ubuntu@ubuntu:~$ ls /bin /usr/bin | sort | uniq | grep zip
There are a couple of handy options for grep: “-i” which causes grep to ignore case
when performing the search (normally searches are case sensitive) and “-v” which tells
grep to only print lines that do not match the pattern.
ubuntu@ubuntu:~$ ls /bin /usr/bin | sort | uniq | grep -i zip
ubuntu@ubuntu:~$ ls /bin /usr/bin | sort | uniq | grep -v zip
head / tail – Print First / Last Part Of Files
Sometimes you don't want all the output from a command. You may only want the first few lines or the last few lines. The head command prints the first ten lines of a file and the tail command prints the last ten lines. By default, both commands print ten lines of
text, but this can be adjusted with the “-n” option:
ubuntu@ubuntu:~$ head -n 5 ls-output.txt
ubuntu@ubuntu:~$ tail -n 5 ls-output.txt
ubuntu@ubuntu:~$ ls /usr/bin | tail -n 5
ok..ok...so today we learn a lot of commands..so at last just sum up what we all learn today...
● cat - Concatenate files
● sort - Sort lines of text
● uniq - Report or omit repeated lines
● grep - Print lines matching a pattern
● wc - Print newline, word, and byte counts for each file
● head - Output the first part of a file
● tail - Output the last part of a file
● tee - Read from standard input and write to standard output and files
thats it for today...and one thing more ..i just upload all the videos of the article what we all cover previously in linux commanding...i hope that help you lot...thank for visiting...like,share....
until next article...
ZEROCOOL
SIGN OUT