> 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]
So I was right. I was expecting pdksh, though (the Public Domain Korn
SHell).
> Three common shells are:
>
> Bourne Shell = sh
> Korn Shell = ksh
> BASH Shell = bash
And what of the C Shell? I read about one version called "tcsh" in a
Linux book. I'm pretty sure it comes with Red Hat 5.0. I really really
wish those guys would hurry up fixing the laptop with Mandrake on it!
All they have to do is fix a broken wire!
> o We change shells simply by naming the new shell
When you name a new shell, you run it. You can exit the new shell with
the "exit" command. Then you'll find yourself in the old shell. It's
like a function call in C--you enter a new function by calling it but
you leave it with a return statement.
> So now we should be able to execute our new command:
>
> $ printpwd
> /u02/home5/rtmyers/testdir
> $
>
> Neat! It works!
Alternately, you can call a shell and tell it to run the shell script
file. "sh printpwd" should do the trick... is this right? In most
shells, ". printpwd" (notice the period) will run a shell script as
well, regardless of the X permission (or the lack thereof). Right?
> And the answer is profound: with this simple procedure,
> we have created our first simple executable script!
Isn't there a convention that the first line of all shell scripts should
be a comment identifying which shell it is to be run with? I believe I
have seen things like:
#!/bin/sh
before. The C Shell requires that shell scripts start with a # comment
line (or was that the Korn Shell?).
> 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.
Shell scripts look very flexible (from what I've read). I haven't had
occasion to write any yet--all I've done is modified existing ones.
