Redirections

Redirection

In this we shall look at redirection of output.

There are three channels that we are aware of,

* stdIn 0 Standard Input
* stdOut 1 Standard Output
* stdErr 2 Standard Error



OUTPUT >, >>, >&

So when you run an application or command on the prompt, The keyboard acts as the stdIn, the terminal is the stdOut and in many cases it is also the stdErr

[student@localhost ~]$ command [arg]



In some cases you might want to capture the output to a file, so the way to do that is

[student@localhost ~]$ command > filename

this shall redirect all output to a file specified as filename and there shall be nothing displayed on the screen. This is the same as specifying

[student@localhost ~]$ command 1> filename

Note that the 1> does not have a space inbetween, if there would be a space then it would be considered as an argument. You could do this with any of the output channels, so you could redirect the stdOut to a file and stdErr to another file. simply by using 1> and 2>

Now, let us look at if you wanted to redirect the stdErr to stdOut (and they were set to be different terminals) you can redirect 2 (stdOut) to 1 (stdIn)

[student@localhost ~]$ command 2> 1

But the flaw with this command is that *nix thinks this is asking you to redirect the stdOut to a file called 1, this is not what we are looking for.

[student@localhost ~]$ command 2>& 1 and hence we use the & sign to specify that this is a channel and not a file

You can have multiple redirections, so take the following example

[student@localhost ~]$ command > filename 2>& 1

this would output the results (stdOut) to a file called filename and the errors (stdErr) to the display terminal (stdIn). Some use case scenarios of such a facility could be when you want to run this command in the background.

NOTE: However the order is most important, if you had used

[student@localhost ~]$ command 2>& 1 > filename

this would be a bit different in the way it works, all the output from the stdErr is being redirected to the stdIn via 2>& 1, in the second bit we are redirecting the stdIn to a file, so what we would get in a file is all the output including the errors, which might not be what we want (or what we want depending on the situation)

Whenever we use the single >, this is redirecting the output to the specified location/channel. Everytime we redirect to a file using the >, the file is overwritten by the new output. If we wish to create like a log file where the data is added to the file rather than overwriting the same, we use the >> redirection.

[student@localhost ~]$ command > filename , would create a file called filename with new contents based on the output of the command.

[student@localhost ~]$ command >> filename , this would append the output of the command to the file called filename which means add to the information that was already there in the file.



INPUT <

Like the output of data, you can also redirect input of data.This could be useful in testing where you might have a file that contains data that you need to test and you can then redirect it to the command using

[student@localhost ~]$ command < input_filename ,where input_filename is the name of the file that is providing the input to the command.

some of you might have used this for testing in CP1300.

iNode

You can read this wikipedia article on iNode found at http://en.wikipedia.org/wiki/Inode

Some intersting excerpts based on discussion with some of you.

It is possible to "run out" of inodes. When this happens, new files cannot be created on the device, even though there may be free space available.

The properties of a file system that makes use of inodes surprise many users who are not used to the concept:

• If multiple names link to the same inode (they are all hard links to it) then all of the names are equivalent. The first one to have been created has no special status. This is unlike the sometimes more familiar symbolic links, where all of the links depend on the original name.

• An inode can even have no links at all. Normally such a file would be removed from the disk and its resources freed for reallocation (the normal process of deleting a file) but if any processes are holding the file open, they may continue to access it, and the file will only be finally deleted when the last reference to it is closed. This includes executable images which are implicitly held open by the processes executing them. For this reason, when programs are updated, it is recommended to delete the old executable first and create a new inode for the updated version, so that any instances of the old version currently executing may continue to do so unbothered.

• Typically, it is not possible to map from an open file to the filename that was used to open it. The operating system would convert the filename to an inode number at the first possible chance, then forget the filename. This means that the getcwd() and getwd() library functions would need to search the parent directory to find a file with an inode matching the "." directory, then search the grandparent directory for that directory, and so on until reaching the "/" directory. SVR4 and Linux systems retain extra information to avoid this awkwardness.

• Historically, it was possible to hard link directories. This made the directory structure into an arbitrary directed graph as opposed to a directed acyclic graph (DAG), a connected graph with N-1 edges for N nodes. For example, it was possible for a directory to be its own parent. Modern systems generally prohibit this confusing state, except that the root directory is still its own parent.
• A file's inode number will stay the same when it is moved to another directory on the same device, or when the disk is defragmented. Therefore, moving either a file's directory entry or its data (or both) is not enough to prevent a running process from accessing it, if the process ever had a chance of finding out the inode number. This also implies that completely conforming behavior of inodes is impossible to implement with many non-Unix file systems, such as FAT and its descendants, which don't have a way of storing this lasting "sameness" when both a file's directory entry and its data are moved around.

• Installation of new libraries is simple with inode filesystems. Take the following example: A currently running process can have a library mapped, while another process replaces that file (creating a new inode), all new mapping of that library will be of the new file. This eliminates the need to reboot to replace currently mapped libraries.

File names and directory implications:

• Inodes do not contain file names, only file metadata.
• Unix directories are lists of "link" structures, each of which contains one filename and one inode number.
• The kernel must search a directory looking for a particular filename and then convert the filename to the correct corresponding inode number if the name is found.

Important '/etc' Files

/etc files

there are a lot of files on a *nix system. you are aware that the /etc directory generally contains .conf files. '.conf' are configuration files. There are other configuration files that are used by the system. I am attempting to list out a few important ones that you might need to know.

• fstab - FileSystemTable, contains all mapping information about file systems to devices
• mtab - Contains the currently mounted file systems
  
• group - The groups defined on the system
• inittab - The config file for the Init process when the system starts
• motd - The Message Of the day, shows up when you log in (Try on Dunk, it gives you the long welcome message)
• passwd - The user information file
• shadow - The file that contains pasword hashes
  
• profile - The script that runs and sets the global defaults for all users

You can read further into the contents of these files to get an idea of what they contain and what you need to change and can change.

Starting with Shell Script

What is a Shell Script?

A shell script is a text file that is interpreted as a series of commands executed one after the other to achieve the desired result. It can cater for interactivity and complexity where decisions are required on certain conditions.

Here is an example of what a shell script looks like

#!/bin/bash
#
# Prog: Sample Shell Script, outputs Hello World
# Author : Jayant C Varma
#
echo "Hello World"

What does it all mean?
The first line indicates to the kernel that this is a script. So every script should start with the first line being #!/bin/bash , now if one was to use python or perl as the scripting language instead of bash, then the line would correspondingly change to #!/usr/bin/python or #!/bin/perl , The path that folows the #! is the path to where the interpreter lies, so if you have a custom language that you might want to use, you can specify the path to the interpreter and it would work.

The # is a comment, and it is a good idea to document and write on the top after the first line about the author and the function of the program.

The main guts of the program that outputs the data is the line echo "Hello World" that prints to the terminal the words Hello World.

Is that all that is required to make a script?
Yes, that is all that is required to make a script. Running the file on its own will not work as it is just a text file. So to run it we can use the command line

$ > bash myscript.sh

this shall run the script caled myscript.sh

To make the script run on its own, we need to midify the file from being an ordinary file to an executable file, we do so by changing the file permissions using the command chmod.

$ > chmod +x myscript.sh

Now the myscript.sh file is no longer an odinary text file, but an executable script file
to run the same, we can simply type, at the command line

$ > ./myscript.sh

We shall see in other posts why do we use the ./ before the filename instead of just typing the myscript.sh, an exercise for you, try it out and see what happens if you do not include the ./

Shell Scripting

One of the advantages of Linux/UNIX is that it was not build as a GUI based Operating System. It was a System Administrators OS that was text based (Terminal based) and multi-tasking. Catering for every utility that might be used for system administration would be difficult. A text based scripting language was developed. This is a very powerful and can allow for a multitude of complex operations, right from setting permissions to performing interactive installations.

To extend the capabilities of the scripting language, two additional utilities were developed called AWK and SED. They are quite useful and complex and deserve a book on themselves.