Q.1. Give introduction to UNIX operating system and its history.
Ans.:-
The UNIX system
The Unix system is a multi-user,
multi
tasking operating
system which means that it allows a single or multiprocessor
computer to simultaneously execute several programs by one or several
users. It has one or several command interpreters (shell) as well as
a great number of commands and many utilities (assembler, compilers
for many languages, text processing, email, etc.). Furthermore, it is
highly portable, which means that it is possible to implement a Unix
system on almost all hardware platforms.
Currently, Unix systems have
a strong foothold in professional and university environments thanks
to their stability, their increased level of security and observance
of standards, notably in terms of networks.
The history of UNIX systems
The first "Unix" system was
developed by Ken Thompson in the Bell AT&T laboratories at Murray
Hill in New Jersey in the United States from 1965. Ken Thompson's aim
was to develop a simple interactive operating system, called
"Multics" (Multiplexed Information and Computing System)
in order to run a game which he had created (space travel, a
simulation of the solar system).
A consortium made up of MIT (Massachesetts
Institute of Technology), General Electric Co. and Bell
Lab was then formed around Multics.
In April 1969 the AT&T laboratories
decided to use the GECOS (General Electric Comprehensive
Operating System ) instead of Multics. However, Ken
Thompson and Dennis Ritchie who joined the team needed to
make the space travel game work on a smaller machine (a DEC
PDP-7, Programmed Data Processor which only had 4K of
memory to make user programs run), this is why they recreated the
system in order to create a limited version of Multics called
UNICS (UNiplexed Information and Computing Service),
quickly shortened to Unix.
The date of 1st January 1970 is
considered as the birth date of the UNIX system, which explains why
all system clocks for Unix operating systems start from this date.
Alongside these activities, D.Ritchie played
a large part in the definition of the C language (since he is
considered as one of its creators with B.W.Kernighan), so the
whole system was entirely rewritten in C in 1973 and called Unix
Time-Sharing System (TSS).
When the system passed version 7 in 1979, its development was accompanied by many notable modifications such as:
When the system passed version 7 in 1979, its development was accompanied by many notable modifications such as:
- the removal of limitations linked to file sizes,
- better portability of the system (operating on many hardware platforms),
- the addition of many utilities.
A decree dating from 1956 prevented the company ATT,
to which Bell Labs belonged, from marketing anything other
than telephone or telegraph equipment, this is why the decision was
taken in 1973 to distribute UNIX source into universities for
educational purposes.
From the end of 1977 researchers from the University
of California redeveloped a version of Unix from source supplied by
AT&T in order to run the system on their VAX platforms and
called it BSD for Berkeley Software Development.
So two development branches of the source grew:
- The AT&T branch which would become System V from UNIX System Labs (USL)
- BSD (Berkeley Software Development) developed
by the University of California
In 1977 AT&T made the UNIX source available to
other companies, although a great number of UNIX-like systems were
developed:
- AIX, commercial Unix based on System V developed in February 1990 by IBM
- Sun Solaris, commercial Unix based on System V and BSD developed by SUN Microsystems
- HP-UX, commercial Unix based on BSD developed from 1986 by Hewlett Packard
- Ultrix, commercial Unix developed by DEC
- IRIX, commercial Unix developed by SGI
- Unixware, commercial Unix developed by Novell
- Unix SCO, commercial Unix based on System V developed from 1979 by Santa Cruz Operations and Hewlett Packard
- Tru64 UNIX, commercial Unix developed by Compaq
Q.2. Study different
UNIX layers and file systems.
ANS.:-
The UNIX operating
system is made up of three parts: the kernel, the shell and the
programs.
The kernel
The kernel of UNIX
is the hub of the operating system: it allocates time and memory
toprograms and handles the filestore and communications in response
to system calls.
The shell
The shell acts as an
interface between the user and the kernel. The shell is a commandline
interpreter (CLI). It interprets the commands the user types in and
arranges for themto be carried out. The commands are themselves
programs: when they terminate, theshell gives the user another prompt
($ on our systems).
The programs
A program is
refereed to as a process while the kernel is running it. The Kernel
can runthe same shell program(or any other program) simultaneously
for many users on a UnixSystem, and each running copy of the program
is a separate process. The Shell is also aprogram that the UNIX
Kernel runs for the user.
The UNIX File System
Most UNIX machines store their files on magnetic disk drives. A disk drive is a device that can store information by making electrical imprints on a magnetic surface. One or more heads skim close to the spinning magnetic plate, and can detect, or change, the magnetic state of a given spot on the disk. The drives use disk controllers to position the head at the correct place at the correct time to read from, or write to, the magnetic surface of the plate. It is often possible to partition a single disk drive into more than one logical storage area. This section describes how the UNIX operating system deals with a raw storage device like a disk drive, and how it manages to make organized use of the space.How the UNIX file system works
Every item in a UNIX file system can de defined as belonging to one of four possible types:- Ordinary files
- Ordinary files can contain text, data, or program information. An ordinary file cannot contain another file, or directory. An ordinary file can be thought of as a one-dimensional array of bytes.
- Directories
- In a previous section, we described directories as containers that can hold files, and other directories. A directory is actually implemented as a file that has one line for each item contained within the directory. Each line in a directory file contains only the name of the item, and a numerical reference to the location of the item. The reference is called an i-number, and is an index to a table known as the i-list. The i-list is a complete list of all the storage space available to the file system.
- Special files
- Special files represent input/output (i/o) devices, like a tty (terminal), a disk drive, or a printer. Because UNIX treats such devices as files, a degree of compatibility can be achieved between device i/o, and ordinary file i/o, allowing for the more efficient use of software. Special files can be either character special files, that deal with streams of characters, or block special files, that operate on larger blocks of data. Typical block sizes are 512 bytes, 1024 bytes, and 2048 bytes.
- Links
- A link is a pointer to another file. Remember that a directory is nothing more than a list of the names and i-numbers of files. A directory entry can be a hard link, in which the i-number points directly to another file. A hard link to a file is indistinguishable from the file itself. When a hard link is made, then the i-numbers of two different directory file entries point to the same inode. For that reason, hard links cannot span across file systems. A soft link (or symbolic link) provides an indirect pointer to a file. A soft link is implemented as a directory file entry containing a pathname. Soft links are distinguishable from files, and can span across file systems. Not all versions of UNIX support soft links.
The I-List
When we speak of a UNIX file system, we are actually referring to an area of physical memory represented by a single i-list. A UNIX machine may be connected to several file systems, each with its own i-list. One of those i-lists points to a special storage area, known as the root file system. The root file system contains the files for the operating system itself, and must be available at all times. Other file systems are removable. Removable file systems can be attached, or mounted, to the root file system. Typically, an empty directory is created on the root file system as a mount point, and a removable file system is attached there. When you issue a cd command to access the files and directories of a mounted removable file system, your file operations will be controlled through the i-list of the removable file system.The purpose of the i-list is to provide the operating system with a map into the memory of some physical storage device. The map is continually being revised, as the files are created and removed, and as they shrink and grow in size. Thus, the mechanism of mapping must be very flexible to accomodate drastic changes in the number and size of files. The i-list is stored in a known location, on the same memory storage device that it maps.
Each entry in an i-list is called an i-node. An i-node is a complex structure that provides the necessary flexibility to track the changing file system. The i-nodes contain the information necessary to get information from the storage device, which typically communicates in fixed-size disk blocks. An i-node contains 10 direct pointers, which point to disk blocks on the storage device. In addition, each i-node also contains one indirect pointer, one double indirect pointer, and one triple indirect pointer. The indirect pointer points to a block of direct pointers. The double indirect pointer points to a block of indirect pointers, and the triple indirect pointer points to a block of double indirect pointers. By structuring the pointers in a geometric fashion, a single i-node can represent a very large file.
It now makes a little more sense to view a UNIX directory as a list of i-numbers, each i-number referencing a specific i-node on a specific i-list. The operating system traces its way through a file path by following the i-nodes until it reaches the direct pointers that contain the actual location of the file on the storage device.
The file system table
Each file system that is mounted on a UNIX machine is accessed through its own block special file. The information on each of the block special files is kept in a system database called the file system table, and is usually located in /etc/fstab. It includes information about the name of the device, the directory name under which it will be mounted, and the read and write privileges for the device. It is possible to mount a file system as "read-only," to prevent users from changing anything.File system quotas
Although not originally part of the UNIX filesystem, quotas quickly became a widely-used tool. Quotas allow the system administrator to place limits on the amount of space the users can allocate. Quotas usually place restrictions on the amount of space, and the number of files, that a user can take. The limit can be a soft limit, where only a warning is generated, or a hard limit, where no further operations that create files will be allowed.The command
- quota
File system related commands
Here are some commands related to file system usage, and other topics discussed in this section:- new file system (super user only)
- fsck
- Evaluates the integrity of a file system (super user only)
A brief tour of the UNIX filesystem
The actual locations and names of certain system configuration files will differ under different inplementations of UNIX. Here are some examples of important files and directories under version 9 of the HP-UX operating system:- /hp-ux
- The kernel program
- /dev/
- Where special files are kept
- /bin/
- Executable system utilities, like sh, cp, rm
- /etc/
- System configuration files and databases
- /lib/
- Operating system and programming libraries
- /tmp/
- System scratch files (all users can write here)
- /lost+found/
- Where the file system checker puts detached files
- /usr/bin/
- Additional user commands
- /usr/include/
- Standard system header files
- /usr/lib/
- More programming and system call libraries
- /usr/local/
- Typically a place where local utilities go
- /usr/man
- The manual pages are kept here
Other places to look for useful stuff
If you get an account on an unfamiliar UNIX system, take a tour of the directories listed above, and familiarize yourself with their contents. Another way to find out what is available is to look at the contents of your PATH environment variable:- echo $PATH
- You can use the ls command to list the contents of each directory in your path, and the man command to get help on unfamiliar utilities. A good systems administrator will ensure that manual pages are provided for the utilities installed on the system.bdf
- On HP-UX systems, reports file system usage statistics
- df
- On HP-UX systems, reports on free disk blocks, and i-nodes
- du
- Summarizes disk usage in a specified directory hierarchy
- ln
- Creates a hard link (default), or a soft link (with -s option)
- mount, umount
- Attaches, or detaches, a file system (super user only)
- mkfs
- Constructs a new file system (super user only)
- fsck
- Evaluates the integrity of a file system (super user only)
A brief tour of the UNIX filesystem
The actual locations and names of certain system configuration files will differ under different inplementations of UNIX. Here are some examples of important files and directories under version 9 of the HP-UX operating system:- /hp-ux
- The kernel program
- /dev/
- Where special files are kept
- /bin/
- Executable system utilities, like sh, cp, rm
- /etc/
- System configuration files and databases
- /lib/
- Operating system and programming libraries
- /tmp/
- System scratch files (all users can write here)
- /lost+found/
- Where the file system checker puts detached files
- /usr/bin/
- Additional user commands
- /usr/include/
- Standard system header files
- /usr/lib/
- More programming and system call libraries
- /usr/local/
- Typically a place where local utilities go
- /usr/man
- The manual pages are kept here
Other places to look for useful stuff
If you get an account on an unfamiliar UNIX system, take a tour of the directories listed above, and familiarize yourself with their contents. Another way to find out what is available is to look at the contents of your PATH environment variable:- echo $PATH
Q.3. Give introduction to various internal and external commands in UNIX.
Ans.:-
Internal and External commands:-
UNIX commands are classified into two types
- Internal Commands - Ex: cd, source, fg
- External Commands -
Ex: ls, cat
Let
us look at these in detail
Internal Command:
Internal Command:
Internal
commands are something which is built into the shell. For the shell
built in commands, the execution speed is really high. It is
because no process needs to be spawned for executing it.
For example, when using the "cd" command, no
process is created. The current directory simply gets changed on
executing it.
External
Command:
External
commands are not built into the shell. These are executables
present in a separate file. When an external command has to be
executed, a new process has to be spawned and the command gets
executed. For example, when you execute the "cat"
command, which usually is at /usr/bin, the executable /usr/bin/cat
gets executed.
How
to get the list of Internal commands?
You can get
only if you are in bash shell. Bash shell has a command called
"help" which will list out all the built-in shell
commands.$ help alias [-p] [name[=value] ... ] bg [job_spec ...] bind [-lpvsPVS] [-m keymap] [-f fi break [n] builtin [shell-builtin [arg ...]] caller [EXPR] case WORD in [PATTERN [| PATTERN]. cd [-L|-P] [dir] command [-pVv] command [arg ...] compgen [-abcdefgjksuv] [-o option .....
How to find out whether a
command is internal or external?
type command:
type command:
$ type cd cd is a shell builtin $ type cat cat is /bin/cat
For the internal
commands, the type command will clearly say its shell built-in,
however for the external commands, it gives the path of the command
from where it is executed.
Internal vs External?
The question whether should we use an internal command or an external command OR which is better always does not make sense. Because in most of the situations you will end up using the command which does your job which could be either internal or external.
The big difference in internal vs external command is performance. Internal command are much much faster compared to external for the simple reason that no process needs to be spawned for an internal command since it is all built-into the shell. So, as the size of a script gets bigger, using external commands a lot does adds to its performance.
Not always we get a choice to choose an internal over an external command. However, a careful look at our scripting practices, we might find quite a few places where we can avoid external commands.
Example:
Say to add 2 numbers say x & y:
Not good:
Internal vs External?
The question whether should we use an internal command or an external command OR which is better always does not make sense. Because in most of the situations you will end up using the command which does your job which could be either internal or external.
The big difference in internal vs external command is performance. Internal command are much much faster compared to external for the simple reason that no process needs to be spawned for an internal command since it is all built-into the shell. So, as the size of a script gets bigger, using external commands a lot does adds to its performance.
Not always we get a choice to choose an internal over an external command. However, a careful look at our scripting practices, we might find quite a few places where we can avoid external commands.
Example:
Say to add 2 numbers say x & y:
Not good:
z=`expr $x+$y`
Good:
let z=x+y
let is a shell
built-in command, whereas expr is an external command. Using expr
will be slower. This might be very negligible when you are using it
at an one-off instance. Using it in a place say on every record of
a file containing million records does give a different dimension
to it.