Linux - NewbieThis Linux forum is for members that are new to Linux.
Just starting out and have a question?
If it is not in the man pages or the how-to's this is the place!
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Introduction to Linux - A Hands on Guide
This guide was created as an overview of the Linux Operating System, geared toward new users as an exploration tour and getting started guide, with exercises at the end of each chapter.
For more advanced trainees it can be a desktop reference, and a collection of the base knowledge needed to proceed with system and network administration. This book contains many real life examples derived from the author's experience as a Linux system and network administrator, trainer and consultant. They hope these examples will help you to get a better understanding of the Linux system and that you feel encouraged to try out things on your own.
Click Here to receive this Complete Guide absolutely free.
I would expect most people with much experience in Linux/Unix to do so routinely. I cannot imagine a day going by without using some kind of commandline redirection of standard IO. Its use is part of the fundamental style of Linux/Unix text-mode tools; a set of small tools each doing one thing well, and connecting to solve bigger real world problems.
redirection can input the result of one command into the next command. That can be taken to the next command and so on. The output is normally sent to the screen but can be sent also to a file as well, with the tee command or just to file.
At a simple level it is useful to make a copy of the results of command enquiries,e.g.,
dmesg > file.txt
or you can get the results displayed by a program:
dmesg | less
that would make it easier to read but it is not recorded.
you could do:
dmesg | tee dm1.text | less
This would make and copy to a file while sending to a program that displays the results on the screen in a way that more readable, see man less.
okay,,,i just used the cat command to combine the text of 2 files in the home directory......trying to learn a few things, sometimes just does not sink in to my dense brain fast
I was going to give you examples of doing this but the others did a good job of doing this.
However, there is another redirection that is important. It is the double right arrows. The double right arrows allows you to append data to an existing file. For example, if you did something like this
cat file1 file2 > newfile
Now, lets say you want to add data from file3 to newfile without erasing it. You do it like so
cat file3 >> newfile
Am example of using pipes to extract any info from a program's output
Read the solutions to problems posted in these forums. A fairly high percentage of solutions to commandline-oriented problems will make some use of IO redirection by the shell.
Allow me to speak to the broader subject of standard input and output.
Understanding and making use of the concept of standard IO (and not just in commandline-based applications) is one thing that distinguishes a Windows-work-alike user from a Linux/Unix expert, IMHO. The concept is not complex or difficult, but is under-emphasized by most training material that I've seen. It is an elegant glue that binds together small pieces in order to make bigger systems.
In some cases, it simplifies the creation of more substantial framework systems. For instance, the xinetd daemon leverages the use of stdio by having all of it's sub-member components simply read standard input and write standard output. Because it connects to those sub-components through stdio, it becomes trivial for the writers of those components to gain network access, even though they don't know anything about the network machinery that is in use. Similarly for WWW CGI application writing. The web server just listens for the CGI's standard output data, and forwards it to the client browser. All of the networking is handled by the server, and the CGI application writer is free to focus on the application, knowing that the network machinery is being managed by the component most suited for the task.
Did you know that the concept has been present (in a limited form) on MS OS's since the very early days of MS-DOS?