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.