UNIX

-->

The beginning of Unix operating System

Unix had a modest beginning at AT&T Bell Laboratories in 1969. That was when AT&T withdrew its team from the MULTICS project, and some of them began work on the development of a computing environment to pursue “programming research”. Ken Thompson and Dennis Ritchie then designed and built a small multi-tasking system supporting two users. This new system had an elegant file system, a command interpreter and a set of utilities. A member of the team, Brian Karnighan, presumably having MULTICS in mine, suggested the name UNICS (Then jokingly reared to as the Uniplexed Information And Computer System) for this operating system. In 1970, UNICS finally became the name by which it is known today, UNIX.

Operation systems have always i.e. till UNIX came of the seen, been design with the particular machine in mind. Similarly computers were also built for a specific operation system. They were invariably returned in assembler, which understood and access hardware well, and had good speed. Thomson and Ritchie wanted a general operation system running on more type of hardware. That implied use of high-level language with consequent sacrifice of speed.

Originally written in assembler, UNIX was rewritten in 1973 in C, which was principally authored by Ritchie. Writing the system in C made it possible to maintain it and move it different hardware platforms.

As every vendor modified and enhanced UNIX to create its own version, the orignal UNIX lost its identity as a separate product. All these versions had little resemblance with one another, and each vendor claimed that its product was “true” UNIX. The BSD releases were greatly from the System V releases, and the incompatibilities studily mounted while standards were being developed as to what a product had to satisfy to be called UNIX, AT&T took it upon themselves to rework mainly the BSD product, and ultimately unify the system V3.2, BSD, SunOS and XENIX flavors into a single product. And that is how SVR4 came into being.

IBM, Helwet Packard and digital equipment corporation formed the association called Open Software Foundation (OSF), and was formatted to create an alternative UNIX like operating system. However they had their own brand; IBM offered AIX, HP offered HP-UX, while DEC produced Digital UNIX. And silicon graphics offered AIRIX, system that made Jurassic park possible. The UNIX corporative spirit has also produced Linux, the free UNIX that has captivated the computing words in resent years.

 

 

What Is a Command?

A UNIX command is a series of characters that you type. These characters consist of words that are separated by whitespace. Whitespace is the result of typing one or more Space or Tab keys. The first word is the name of the command. The rest of the words are called the command's arguments. The arguments give the command information that it might need, or specify varying behavior of the command. To invoke a command, simply type the command name, followed by arguments (if any), to indicate to the shell that you are done typing and are ready for the command to be executed, press Enter.

The Types of UNIX Files

There are three types of UNIX files: regular files, directories, and device files. Regular files hold executable programs and data. Executable programs are the commands (such as cat) that you enter. Data is information that you store for later use. Such information can be virtually anything: a book that you are writing, a homework assignment, or a saved spreadsheet.

Directories are files that contain other files and subdirectories, just as a filing cabinet's drawers hold related folders. Directories help you organize your information by keeping closely related files in the same place so you can find them later. For instance, you might save all your spreadsheets in a single directory instead of mixing them

As in the cat example, files can also refer to computer hardware such as terminals and printers. These device files can also refer to tape and disk drives, CD-ROM players, modems, network interfaces, scanners, and any other piece of computer hardware. Under UNIX, even the computer's memory is a file.

Although UNIX treats all files similarly, some require slightly unique treatment. For example, UNIX treats directories especially in some ways. Also, because they refer directly to the computer's hardware, device files sometimes must be treated differently from ordinary files. For instance, most files have a definite size in bytes—the number of characters they contain. Your terminal's keyboard is a device file, but how many characters does it hold? The question of file size doesn't make sense in this case. Despite these differences, UNIX commands usually don't distinguish among the various types of files.

 

 

File and Directory Names

Unlike some operating systems, UNIX gives you great flexibility in how you name files and directories. As previously mentioned, you cannot use the slash character because it is the pathname separator and the name of the file tree's root directory . However, almost everything else is legal. Filenames can contain alphabetic (both upper- and lowercase), numeric, and punctuation characters, control characters, shell wild-card characters (such as *), and even spaces, tabs, and newlines. However, just because you can do something doesn't mean you should. Your life will be much simpler if you stick with upper- and lowercase alphabetics, digits, and punctuation characters such as ., -, and _.

---

CAUTION: Using shell wild-card characters such as * in filenames can cause problems. Your shell expands such wild-card characters to match other files. Suppose that you create a filenamed * that you want to display with cat, and you still have your files cowboys and prufrock. You might think that the command cat * will do the trick, but remember that * is a shell wild card that matches anything. Your shell expands * to match the files *, cowboys, and prufrock, so cat displays all three. You can avoid this problem by quoting the asterisk with a backslash:

$ cat \*

Filenames can be as long as 255 characters in System V Release 4 UNIX. Unlike DOS, which uses the dot character to separate the filename from a three-character suffix, UNIX does not attach any intrinsic significance to dot—a filenamed lots.of.italian.recipes is as legal as lots-of-Italian-recipes. However, most UNIX users follow the dot-suffix conventions listed in Table  Some language compilers like cc require that their input files follow these conventions, so the table labels these conventions as "Required" in the last column.

Table                                                    File suffix conventions.

Suffix	Program	Example	Required
.c	C program files	ls.c	Yes
.f	FORTRAN program files	math.f	Yes
.pl	Perl program files	hose.pl	No
.h	include files	term.h	No
.d, .dir	The file is a directory	recipes.d,	No
		recipes.dir	No
.gz	A file compressed with the	foo.gz	Yes
	GNV project's gzip
.Z	A compressed file	term.h.Z	Yes
.zip	A file compressed with PKZIP	book.zip	Yes

Shell Programming

Introduction

You can do many things without having an extensive knowledge of how they actually work. For example, you can drive a car without understanding the physics of the internal combustion engine. A lack of knowledge of electronics doesn't prevent you from enjoying music from a CD player. You can use a UNIX computer without knowing what the shell is and how it works. However, you will get a lot more out of UNIX if you do.

Three shells are typically available on a UNIX system: Bourne, Korn, and C shells.

• What a shell is
• What a shell does for you
• How a shell relates to the overall system

The Kernel and the Shell

As the shell of a nut provides a protective covering for the kernel inside, a UNIX shell provides a protective outer covering. When you turn on, or "boot up," a UNIX-based computer, the program Unix is loaded into the computer's main memory, where it remains until you shut down the computer. This program, called the kernel, performs many low-level and system-level functions. The kernel is responsible for sending basic instructions to the computer's processor. The kernel is also responsible for running and scheduling processes and for carrying out all input and output. The kernel is the heart of a UNIX system. There is one and only one kernel.

As you might suspect from the critical nature of the kernel's responsibilities, the instructions to the kernel are complex and highly technical. To protect the user from the complexity of the kernel, and to protect the kernel from the shortcomings of the user, a protective shell is built around the kernel. The user makes requests to a shell, which interprets them, and passes them on to the kernel. The remainder of this section explains how this outer layer is built.

Once the kernel is loaded to memory, it is ready to carry out user requests. First, though, a user must log in and make a request. For a user to log in, however, the kernel must know who the user is and how to communicate with him. To do this, the kernel invokes two special programs, getty and login. For every user port—usually referred to as a tty—the kernel invokes the getty program. This process is called spawning. The getty program displays a login prompt and continuously monitors the communication port for any type of input that it assumes is a user name.

When getty receives any input, it calls the login program, as shown in Figure 10.2. The login program establishes the identity of the user and validates his right to log in. The login program checks the password file. If the user fails to enter a valid password, the port is returned to the control of a getty. If the user enters a valid password, login passes control by invoking the program name found in the user's entry in the password file. This program might be a word processor or a spreadsheet, but it usually is a more generic program called a shell.

three shells, developed independently, have become a standard part of UNIX. They are

• The Bourne shell, developed by Stephen Bourne
• The Korn shell, developed by David Korn
• The C shell, developed by Bill Joy

This variety of shells enables you to select the interface that best suits your needs or the one with which you are most familiar.

The Functions of a Shell       

It doesn't matter which of the standard shells you choose, for all three have the same purpose: to provide a user interface to UNIX. To provide this interface, all three offer the same basic functions:

• Command line interpretation
• Program initiation
• Input-output redirection
• Pipeline connection
• Substitution of filenames
• Maintenance of variables
• Environment control
• Shell programming

Command Line Interpretation

When you log in, starting a special version of a shell called an interactive shell, you see a shell prompt, usually in the form of a dollar sign ($), a percent sign (%), or a pound sign (#). When you type a line of input at a shell prompt, the shell tries to interpret it. Input to a shell prompt is sometimes called a command line. The basic format of a command line is

command arguments

command is an executable UNIX command, program, utility, or shell program. The arguments are passed to the executable. Most UNIX utility programs expect arguments to take the following form:

options filenames

For example, in the command line

$ ls -l file1 file2

there are three arguments to ls, the first of which is an option, while the last two are file names.

One of the things the shell does for the kernel is to eliminate unnecessary information. For a computer, one type of unnecessary information is whitespace; therefore, it is important to know what the shell does when it sees whitespace. Whitespace consists of the space character, the horizontal tab, and the new line character. Consider this example:

$ echo part A     part B     part C

part A part B part C

Here, the shell has interpreted the command line as the echo command with six arguments and has removed the whitespace between the arguments. For example, if you were printing headings for a report and you wanted to keep the whitespace, you would have to enclose the data in quotation marks, as in

$ echo 'part A     part B     part C'

part A     part B     part C

The single quotation mark prevents the shell from looking inside the quotes. Now the shell interprets this line as the echo command with a single argument, which happens to be a string of characters including whitespace.

Program Initiation

When the shell finishes interpreting a command line, it initiates the execution of the requested program. The kernel actually executes it. To initiate program execution, the shell searches for the executable file in the directories specified in the PATH environment variable. When it finds the executable file, a subshell is started for the program to run. You should understand that the subshell can establish and manipulate its own environment without affecting the environment of its parent shell. For example, a subshell can change its working directory, but the working directory of the parent shell remains unchanged when the subshell is finished.

Input-output Redirection

 It is the responsibility of the shell to make this happen. The shell does the redirection before it executes the program. Consider these two examples, which use the wc word count utility on a data file with 5 lines:

$ wc -l fivelines

5 fivelines

$ wc -l <fivelines

5

This is a subtle difference. In the first example, wc understands that it is to go out and find a file named fivelines and operate on it. Since wc knows the name of the file it displays it for the user. In the second example, wc sees only data, and does not know where it came from because the shell has done the work of locating and redirecting the data to wc, so wc cannot display the file name.

Pipeline Connection

Since pipeline connections are actually a special case of input-output redirection in which the standard output of one command is piped directly to the standard input of the next command, it follows that pipelining also happens before the program call is made. Consider this command line:

$ who | wc -l

5

In the second example, rather than displaying its output on your screen, the shell has directed the output of who directly to the input of wc. Pipes are discussed in Chapter 4.

Substitution of Filenames

Metacharacters can be used to reference more than one file in a command line. It is the responsibility of the shell to make this substitution. The shell makes this substitution before it executes the program. For example,

$ echo *

file1 file2 file3 file3x file4

Here, the asterisk is expanded to the five filenames, and it is passed to echo as five arguments. If you wanted to echo an asterisk, we would enclose it in quotation marks.

Maintenance of Variables

The shell is capable of maintaining variables. Variables are places where you can store data for later use. You assign a value to a variable with an equal (=) sign.

$ LOOKUP=/usr/mydir

Here, the shell establishes LOOKUP as a variable, and assigns it the value /usr/mydir. Later, you can use the value stored in LOOKUP in a command line by prefacing the variable name with a dollar sign ($). Consider these examples:

$ echo $LOOKUP

/usr/mydir

$ echo LOOKUP

LOOKUP

Environment Control

When the login program invokes your shell, it sets up your environment, which includes your home directory, the type of terminal you are using, and the path that will be searched for executable files. The environment is stored in variables called environmental variables. To change the environment, you simply change a value stored in an environmental variable. For example, to change the terminal type, you change the value in the TERM variable, as in

$ echo $TERM

vt100

$ TERM=ansi

$ echo $TERM

ansi

Shell programming

You've seen that the shell is used to interpret command lines, maintain variables, and execute programs. The shell also is a programming language. By combining commands and variable assignments with flow control and decision-making, you have a powerful programming tool.

The Bourne shell was written by Stephen Bourne at Bell Laboratories, where UNIX was originally developed. Because it is found on most UNIX systems, many software developers work under the assumption that the Bourne shell is available on a UNIX system. This use does not mean that it is the best shell, but simply that it is the most common. Other shells, most notably the Korn shell, were written to enhance the Bourne shell, so shell programs written for Bourne run under the Korn shell. In some literature, the Bourne shell is called the UNIX system Version 7 shell.

The first exposure most people have to the Bourne shell is as an interactive shell. After logging on the system and seeing any messages from the system administrator, the user sees a shell prompt. For users other than the super-user, the default prompt for the interactive Bourne shell is a dollar sign ($). When you see the dollar sign ($), the interactive shell is ready to accept a line of input, which it interprets. When the super-user logs in, he or she sees the pound sign (#) as a prompt. It is a reminder that as super-user some of the built-in protections are not available and that extra care is necessary in this mode.

NOTE: On UNIX systems the super-user, also referred to as root, is without restriction. The super-user can write to any directory and can remove any file. File permissions do not apply to the super-user. The system administrator usually closely holds the password for the super-user.