--------------
Shells,
Redirection
--------------
The shell provides the Command Line Interface that you see
in Linux/UNIX. The shell accepts your input, processes it,
and takes appropriate actions, interfacing with the kernel
and the filesystem as necessary.
The BASH shell was based (partly) upon the Korn Shell, which
was based upon the Bourne Shell. BASH stands for "Bourne Again
SHell".
Examples in some of the emails I send were created using the
Korn Shell. This should make little or no difference, except
for the occasional "switches" to commands which may vary
somewhat.
(I also develop some of this material on SunOS rather
than Linux... Again, little or no difference...
but I hope to have Linux net-connected soon, so that will
change...)
--------------
Digest
--------------
When you encounter an error detected by the shell, it is
normally flagged by the shell. In this example, the shell
is Korn Shell, and the shell designation is "ksh":
$ thisfile
-ksh: thisfile: cannot execute [Permission denied]
$
This identifier did not exist in the original Bourne
Shell. (After all, it was the *only* shell in existence
at the time. Why should it need to identify itself?)
Here is the equivalent Bourne Shell detected error:
$ thisfile
thisfile: execute permission denied
$
The Bourne Shell is a good, simple shell, but is
missing some of the advanced features of later shells.
How do we know what shell we are in?
A variable is something which stores a value. Bourne shell
variables are designated by a preceding $ as in $SHELL
Many systems have a $SHELL variable which shows the shell
we are currently using:
$ echo $SHELL
/bin/sh
$
sh means the Bourne Shell.
The response to the echo $SHELL command shows the path
to the sh file. (Your shell and path may vary from this)
Three common shells are:
Bourne Shell = sh
Korn Shell = ksh
BASH Shell = bash
--------------
In-depth
--------------
Suppose that we start in the Bourne Shell, execute a
command that fails, then we'll move to the Korn and BASH
shells to try the same thing.
>From the command line, you may type:
$ printpwd
printpwd: not found
$
We have attempted to execute a command, but the file
printpwd does not exist (not found).
We switch to the Korn Shell by simply typing ksh.
$ ksh
$
$ printpwd
ksh: printpwd: not found
$
Again, the command is not found. We haven't created it yet!
But notice how this response line differs from the one above.
Now lets try in BASH (which for many of you will be your
startup shell):
$ bash
$
$ printpwd
bash: printpwd: command not found
$
See the difference? We can learn from this that:
o We change shells simply by naming the new shell
o The shell being used is identified on error.
bash: is the first word in the above line...
(but remember that the Bourne Shell was the first
shell, and it still doesn't know there are other
shells out there!)
o The shell detects some errors and identifies
the command which failed (printpwd: in the above line)
o The shell detects and reports, specifically,
*filesearch* errors (the "command not found" in the
above line). Remember that the shell interfaces with
the filesystem?
Now lets create our file:
$ echo pwd > printpwd
$
We redirect the pwd command to a filename printpwd.
Redirection, once again, works via the > command.
printpwd didn't exist before this command; this
command creates it.
If the "target" of a > command does not exist, it is
created as a file. In this case, it is created by the
shell, because the shell handles redirection (more about
that in a later lesson).
The pwd command stands for "print working directory".
If we wish to see what is now in printpwd, we can cat it:
$ cat printpwd
pwd
$
Now we will try (again) to execute our new file:
$ printpwd
bash: ./printpwd: Permission denied
$
Notice the difference between this error and the
previous error-- displayed again here:
bash: printpwd: command not found
At least the shell is able to *find* our command now
(since we created a file with the filename printpwd).
Permission? Oh yes! We need EXECUTE permission to execute
a file. Lets look at the long listing of our new file:
$ ls -l printpwd
-rw-r--r-- 1 rtmyers other 4 Jul 28 16:20 printpwd
$
Our permissions string is -rw-r--r--
There are no "x's" in our permissions string.
The chmod command changes permissions for us, and +x
gives us (global) execute permissions:
$ chmod +x printpwd
$
Lets take another look:
$ ls -l printpwd
-rwxr-xr-x 1 rtmyers other 4 Jul 28 16:20 printpwd
$
Now we've got x's. (More about this in a later lesson)
So now we should be able to execute our new command:
$ printpwd
/u02/home5/rtmyers/testdir
$
Neat! It works!
We have executed the pwd command, by calling the name
of a file (which has been given execute permissions)
that simply includes the pwd command.
But now we are faced with a disturbing recognition:
...we COULD have executed pwd just by calling the
pwd command directly!
$ pwd
/u02/home5/rtmyers/testdir
$
Why on earth did we go to all of the trouble to call
it indirectly by putting the pwd command in another file
and then calling that file?
And the answer is profound: with this simple procedure,
we have created our first simple executable script! We
don't have to content ourself with one command, we can
put in multiple commands. Also, data structures, and
program logic, and other nifty stuff.
With these simple techniques, we can build scripts that
can do amazing things! Even UNIX!
_______________________________ end ___________________________
best wishes,
richard myers
