Re: [newbie] UNIX INTRO: Shells, redirection
So I was right. I was expecting pdksh, though (the Public Domain Korn
SHell).
It appears that the maillist switched the order of my two posts.
Yes, the demonic mailer daemon strikes again...
Yes, Korn
Shell. In my experience pdksh is not a good substitute for ksh (although
my experience was years ago; not sure of the current status).
I think I'll stick to BASH.
And what of the C Shell?
I have used the C Shell, and it provides a nice interface. However, csh is
worse than worthless for creating scripts:
The name looked so promising! My first impression (based on the name
alone) led me to assume that I could write scripts like:
if (x)
{
doSomething();
}
(i.e. using C syntax, which I think is just lovely)
After actually reading about it, I was left with the question, "Why the
HELL is this called the C Shell anyway? Is it just a clever way of
saying seashell?"
quote
Unix Support frequently advises people not to use /bin/csh. Here is the
classic document by Tom Christiansen on why you shouldn't use it for
scripts.
Csh Programming Considered Harmful
shudder I think I'll stick to BASH.
...I read about one version called "tcsh" in a
Linux book.
I've heard it is improved. I'd do some research before I started using it,
however. The above URL is a good place to start, it mentions tcsh.
I don't think I read what "t" stands for... "The" perhaps?
#!/bin/sh
In the UNIX world, there are basically two types of shell scripts-- those
based upon the Bourne Shell (including Korn Shell and BASH), and those
based upon the C Shell. The common shell language for writing portable
scripts is the Bourne Shell. Advanced features of other shells are to be
avoided unless the script is never expected to leave the target system.
Once again, I'll do BASH. If I want more features, I'll move up to
another language (AWK, PERL, C, C++, Tcl, ...). Or I could write a
little utility program in one of these other languages and call it from
a shell script. In my DOS batch programming, I would fill in all the
holes with plenty of cool .com programs that usually just called an
interrupt or two.
There may be other considerations for Linux. It seems that BASH has become
pretty much a standard.
I can see why.
Hey. I have a BASH question. On my computer running Red Hat 5.0, BASH
doesn't take kindly to the DEL key. Whenever I press it, it beeps at me
and emits a ~ into the command line. DEL works in emacs... why not
BASH? I'd also like to be able to map HOME and END to what emacs's
Ctrl+A and Ctrl+E (well, the go-to-end-of-line shortcut). Any tips?
The #! convention is an interesting story. Too long for posting here; I
refer you to:
16 bits, right?) When the `#!' magic number was recognized, the
kernel would read in the rest of the line and treat it as a
command to run upon the contents of the file. With this hack you
I wonder what #! assembles to... I hope it's nothing meaningful!
P.S. Is anyone else here aware of the BAND Korn? Very cool stuff... not
UNIX-related (All day I dream about sex... all day I dream about
@#$!ing...) though.
[newbie] UNIX INTRO: Shells, redirection
-- 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
Re: [newbie] UNIX INTRO: Shells, redirection
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.
Re: [newbie] UNIX INTRO: Shells, redirection
From: Andy Goth [EMAIL PROTECTED] 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 Both of those will run a script, but there's a difference. "sh printpwd" will run the script in a new instance of the shell.
Re: [newbie] UNIX INTRO: Shells, redirection
From: Dan Brown [EMAIL PROTECTED] From: Andy Goth [EMAIL PROTECTED] 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 Both of those will run a script, but there's a difference. "sh printpwd" will run the script in a new instance of the shell. now to finish the message... Running the script in a new instance of the shell means it spawns another shell which runs the script, and then terminates. Running ". printpwd" (or "source printpwd", which is the same thing) runs the shell in the currently-running shell, not spawning a new one. Usually, this doesn't make much difference. However, if you are using the script to set environment variables (like the prompt, for example), the difference is significant.
Re: [newbie] UNIX INTRO: Shells, redirection
$ thisfile -ksh: thisfile: cannot execute [Permission denied] On Thu, 29 Jul 1999, Andy Goth wrote: So I was right. I was expecting pdksh, though (the Public Domain Korn SHell). It appears that the maillist switched the order of my two posts. Yes, Korn Shell. In my experience pdksh is not a good substitute for ksh (although my experience was years ago; not sure of the current status). And what of the C Shell? I have used the C Shell, and it provides a nice interface. However, csh is worse than worthless for creating scripts: quote Unix Support frequently advises people not to use /bin/csh. Here is the classic document by Tom Christiansen on why you shouldn't use it for scripts. Csh Programming Considered Harmful Resolved: The csh is a tool utterly inadequate for programming, and its use for such purposes should be strictly banned. I am continually shocked and dismayed to see people write test cases, install scripts, and other random hackery using the csh. /quote See the complete article at: http://vega.ing.iac.es/~cfg/notes/pub_notes/csh.html ...I read about one version called "tcsh" in a Linux book. I've heard it is improved. I'd do some research before I started using it, however. The above URL is a good place to start, it mentions tcsh. 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 In the UNIX world, there are basically two types of shell scripts-- those based upon the Bourne Shell (including Korn Shell and BASH), and those based upon the C Shell. The common shell language for writing portable scripts is the Bourne Shell. Advanced features of other shells are to be avoided unless the script is never expected to leave the target system. There may be other considerations for Linux. It seems that BASH has become pretty much a standard. The #! convention is an interesting story. Too long for posting here; I refer you to: unix/faq Digest part 3 of 7 by Ted Timar - [EMAIL PROTECTED] It is a regular posting in comp.unix.shell, or check out: http://www.faqs.org/faqs/by-newsgroup/comp/comp.unix.shell.html Here is just an excerpt: quote 3.16) Why do some scripts start with #! ... ? [...] The Berkeley folks had a neat idea to extend how the kernel starts up programs. They hacked the kernel to recognize the magic number `#!'. (Magic numbers are 16-bits and two 8-bit characters makes 16 bits, right?) When the `#!' magic number was recognized, the kernel would read in the rest of the line and treat it as a command to run upon the contents of the file. With this hack you could now do things like: #! /bin/sh #! /bin/csh #! /bin/awk -F: This hack has existed solely in the Berkeley world, and has migrated to USG kernels as part of System V Release 4. [...] /quote best wishes, richard myers
