eXtropia: the open web technology company
Technology | Support | Tutorials | Development | About Us | Users | Contact Us
Resources
 ::   Tutorials
 ::   Presentations
Perl & CGI tutorials
 ::   Intro to Perl/CGI and HTML Forms
 ::   Intro to Windows Perl
 ::   Intro to Perl 5
 ::   Intro to Perl
 ::   Intro to Perl Taint mode
 ::   Sherlock Holmes and the Case of the Broken CGI Script
 ::   Writing COM Components in Perl

Java tutorials
 ::   Intro to Java
 ::   Cross Browser Java

Misc technical tutorials
 ::   Intro to The Web Application Development Environment
 ::   Introduction to XML
 ::   Intro to Web Design
 ::   Intro to Web Security
 ::   Databases for Web Developers
 ::   UNIX for Web Developers
 ::   Intro to Adobe Photoshop
 ::   Web Programming 101
 ::   Introduction to Microsoft DNA

Misc non-technical tutorials
 ::   Misc Technopreneurship Docs
 ::   What is a Webmaster?
 ::   What is the open source business model?
 ::   Technical writing
 ::   Small and mid-sized businesses on the Web

Offsite tutorials
 ::   ISAPI Perl Primer
 ::   Serving up web server basics
 ::   Introduction to Java (Parts 1 and 2) in Slovak

 

Introduction to UNIX for Web Developers
UNIX Shells  
As we said, since the kernel is responsible for so many complex tasks (translation, memory and file system management, etc), it typically cannot spend too much time making life too easy for the person using it. Its user interface, though much better than that of the hardware, still sucks for the average user.

Fortunately, UNIX implements another layer of abstraction that envelops the kernel. This next layer is called a shell.

The benefit of a shell, of course, is that it is built primarily for people. Time and energy have been taken to develop a user-friendly interface with a language more intelligible than either the language of the hardware or that of the kernel.

The most basic UNIX shell provides a "command line" which allows you to type in commands which are translated by the shell into kernel speak and sent off to the kernel. The following image shows a comand line:

[Spacer] [Command Line]

[Spacer]
However, UNIX has not kept its head in the sand completely in the age of GUI. There are many excellent windowing systems which provide a much better user interface than a command line such as what is available through X-Windows or IRIX.

As we said, you use the command line to send commands to the shell. The shell translates those commands into kernel speak. And finally, the kernel sends them on to the hardware. The image below shows the relationship

[Shells]

At this point you might be wondering why the heck there are so many translator layers between you and the hardware.

Well, this architecture follows the most basic principle of UNIX development:

Thou shalt design a community of small objects which will do only one thing, but do that one thing very well.

The developers of UNIX realised that several pieces which each do their one job well and know how to cooperate is a much better way to design software than to create one monolithic, all-knowing monster which is always breaking out of its cage and doing unpredictable and destructive things.

Thus, in UNIX, the hardware can focus solely on electronics, the kernel can focus on talking to the hardware and the shell can focus on talking to the user. Each piece has a limited task so it is able to that one task with efficiency and simplicity.

Of course, nothing is ever as simple as it is in theory. Though you will always use a shell when you are doing your work, "which" shell you will use will depend on the system you are working on. There are several basic command-line shells in use today and each has a slightly different interface and capabilities. Fortunately, they do share most of the same generic properties so it is fairly easy to switch between them.

The first UNIX shell was the Bourne Shell which is commonly abbreviated as "sh". Though this is the default shell which comes with every version of UNIX, it is the oldest and least shnazy of the shells since it has not been modified in several decades and has thus not kept up with interface advances.

The C Shell was created next at Berkeley and added several cool features like command line editing and history management. Unfortunately it was not particularly compatible with the Bourne Shell.

The Korn came next to take the good from both the C Shell and the Bourne Shell.

At any rate, by now there are quite a few standard shells as well as a host of proprietary ones. The following table lists the ones you will most often see

Name Abbreviation Info
Bourne Shell sh The oldest of the shells which was designed by Steve Bourne. It is considered a bit primitive but very good for scripting.
C Shell csh The C Shell is probably the most popular. However, though it adds many nice features (like history and job control) unavailable in the Bourne Shell, it is quite buggy for heavy users.
Korn Shell ksh David Korn wrote this shell to be compatible with the Bourne Shell but include te cool features introduced by the C Shell. However, it did the C Shell one step further and introduced history editing.
Bourne Again Shell bash Similar to the Korn Shell but with some additional features like a built in help command.
tcsh tsch An extended version of the C Shell with the features introduced by ksh and bash.

It is most likely that any UNIX system you use will have several or all of the shells installed so you can choose whichever one you are most comfortable with. The main thing to remember is that you should choose one that has the features which help you do your own special kind of work. Spend some time playing with each shell to see what they offer and how they differ.

However, it remains to be seen what you actually do with the shell. Well, the most basic activity is that of executing utilities. Let's examine utilities.

Previous | Next | Table of Contents