Re: [newbie] UNIX INTRO: Shell Processing
$ cat abcfile xyzfile This is the contents of xyzfile $ If anyone has an answer to this, tell us! Try tracing it. We can use a very important trick to find out: set -x - - What shells does that work with? UX, I know, but BASH? $ set -x $ $ cat abcfile xyzfile + cat xyzfile + 0 abcfile xyz $ "0"? $ set -x $ echo xyzfile + echo + 0 xyzfile $ "0"? $ echo x /dev/null + echo x + 1 /dev/null $ "1"? I've seen 2 before for redirecting STDERR. So, these streams have numbers... I know that 2 is for STDERR, and I can see (from the above example) that 1 is for STDOUT. 0? Nowhere? The bit bucket?
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: lessons declared open source
Because: o Open source works better than closed source; and o The lessons were developed partly using ksh rather than BASH; and o It is entirely possible that there could be undetected errors; and o Additional contributors will make the lessons better, I hereby declare: ...that everyone is invited and welcome to test the lessons on their Linux installations, particularly using the BASH shell, and to send me any corrections, suggestions for improvements, suggestions for new lessons, or even developed lessons in similar format. Maybe we can make something worthwhile out of these sessions for all new Linux users. (No, I'm not going to go to all the trouble of issuing a GPL at this time... grin...) Note: I'm not experienced enough (by a few lightyears!) to offer similar material on system admin issues. Well, there is the Linux Documentation Project. But that is more task-oriented than training-oriented. There may already be worthwhile efforts of this sort somewhere in cyberspace, which could provide cross-fertilization. Anyone know of any? best wishes, richard myers
Re: [newbie] UNIX INTRO: lessons declared open source
An aside..Or should I say: A peripheral issue.. I don't work with computer technology except to type lesson plans and make instructional materials for ESL classes I teach to adults. So, much of what I study about Unix or Linux is lost through my lack of use of it in my daily work. So, I wonder if there is somewhere a list of problems and solutions for Unix or Linux, a workbook as it were. Something that presents technical problems to the nontechnical user to help us practice what we learn. And I am approaching 60 years of age, so I find this to be even more necessary as my memory and learning capacities begin to slowly shutdown. Does anyone know of such a thing? Is anyone interested in collaborating on creating such a thing? By the way, I use linux as a desktop system, and I like 3% more than Windows. All the stuff about it not being ready for prime time is bullshit. adios, STeve W --- Richard Myers [EMAIL PROTECTED] wrote: Because: o Open source works better than closed source; and o The lessons were developed partly using ksh rather than BASH; and o It is entirely possible that there could be undetected errors; and o Additional contributors will make the lessons better, I hereby declare: ...that everyone is invited and welcome to test the lessons on their Linux installations, particularly using the BASH shell, and to send me any corrections, suggestions for improvements, suggestions for new lessons, or even developed lessons in similar format. Maybe we can make something worthwhile out of these sessions for all new Linux users. (No, I'm not going to go to all the trouble of issuing a GPL at this time... grin...) Note: I'm not experienced enough (by a few lightyears!) to offer similar material on system admin issues. Well, there is the Linux Documentation Project. But that is more task-oriented than training-oriented. There may already be worthwhile efforts of this sort somewhere in cyberspace, which could provide cross-fertilization. Anyone know of any? best wishes, richard myers _ Do You Yahoo!? Free instant messaging and more at http://messenger.yahoo.com
[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
[newbie] UNIX INTRO: Pipes and Redirection
-- Pipes and Redirection -- Someone wrote: : OK...I thought I had it all straight in my mind but : I now find the difference between redirection and : pipes really foggy. Is there something absolute I : can put in my mind to clarify the two? EXCELLENT question!!! -- Digest -- Redirection is a mechanism in the shell that causes the standard input for a program to come from a file rather than from the terminal. It also causes the standard output and standard error to go to a file rather than to the terminal. (Standard output, standard error? Later lesson!) Input redirection is symbolized by the character. Output is the character, and output with append uses the characters. A pipe is a mechanism used by one command to pass information to a second command for processing; a pipe connects the standard output of one command to the standard input of the next, without creating an intermediate file. A pipe is symbolized by the vertical bar | character. -- In-depth -- I don't know of any easy way to learn the difference, other than to practice and see what works: $ echo this thisfile $ cat thisfile this $ We have redirected the output of echo to a file. We can then cat the file and display what is in it. Now try piping from echo to a file: $ echo this | thisfile -ksh: thisfile: cannot execute [Permission denied] $ As you can see, this does not work. However, we can pipe from one command to another: $ echo this | cat this $ This is a redundant operation. It would win the "useless use of cat" award (more about that later). However, it works without generating an error (important for our purposes), and this next step proves that *echo* isn't displaying "this" to the screen, *cat* is. Now lets try to redirect to cat and see what happens: $ echo this cat $ Well, what happened to our output? It didn't appear on the screen! We can find it if we look for redirection to a file using cat: $ cat cat this $ Aha! In the previous command we redirected the string "this" to a newly-created file called cat, and we can display that file with cat. As a general guideline, then, redirection seems to work with files, and piping works with commands. It does get a bit more complicated later on, but for now that is a good way to tell the difference. Lets try one more example. The wc command does word counting, and this particular behavior is turned on with the -w switch. Thus: $ echo this | wc -w 1 $ We have echoed one word to wc -w. $ echo this that | wc -w 2 $ $ echo this that other | wc -w 3 $ ...and a two, and a three... Now lets try redirecting three words to wc -w (instead of piping). $ echo this that other wc -w $ No output. No error. That means our command was successful, but maybe didn't do what we wanted (since we were expecting output to the screen). We can find the file created with redirection by using ls: $ ls wc $ And now for the mysterious part: $ cat wc this that other -w $ Our words were not counted, they were redirected into a file which has the filename wc. But how did that -w get in there? Ahhh, but that is the subject of a later lesson! ___ end ___ Errata: it IS possible to pipe to a file. How? Because (as we saw in the last lesson) a file can become a command. But piping to a user-created command is an advanced technique, and we aren't going to explore that right away. best wishes, richard myers
Re: [newbie] UNIX INTRO: Pipes and Redirection
Input redirection is symbolized by the character. Output is the character, and output with append uses the characters. That's like DOS (except that MORE FILE doesn't seem to work). $ echo this | thisfile -ksh: thisfile: cannot execute [Permission denied] KSH? Korn Shell? This is a redundant operation. It would win the "useless use of cat" award How about ls | cat | cat ? That's even worse! $ echo this that other wc -w $ cat wc this that other -w $ Our words were not counted, they were redirected into a file which has the filename wc. But how did that -w get in there? Ahhh, but that is the subject of a later lesson! Weird... I want to know! Errata: it IS possible to pipe to a file. How? Because (as we saw in the last lesson) a file can become a command. And what about piping STDERR? But piping to a user-created command is an advanced technique, and we aren't going to explore that right away. I wrote a DOS program that would accept piped input (STDIN, I believe...) and display it to a graphics mode using a custom font. It locked up since I didn't know when to stop taking input! There is some character to flag the end, but I am unsure But that was DOS. We're talking UNIX here.
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
RE: [newbie] UNIX INTRO: Philosophy and pipes
First, I apologize if this comes out in HTML. I just installed Outlook 97 for trouble-shooting purposes and haven't yet figured out how to turn off the "styled text" yet not even sure it's possible. *sigh* [mega-clip] But suppose we want all filenames with dates on the first of the month (maybe bills are due?). So we use sort as a filter, piping the output of sort to the grep command. The grep command will print ONLY those lines that include our "grepped for" text: $ ls | sort -M | grep 01 jan.01 jul.01 sep.01 $ Voila! Using the pipe commands, our output from the LIST command "ls" is filtered through "sort" and then through "grep" to give us just what we want, and nothing more: a list of filenames sorted by date, including only the dates for the first of each month. ls is a program, and so is sort, and so is grep. The pipes are a feature of the shell, but we'll learn about that later. -- Thanks for this insightful use of multiple applications and combining them with the pipe command. I never realized you could string these commands together. I see I'm going to learn a LOT from this discussion! :-) John
Re: [newbie] UNIX INTRO: Philosophy and pipes
-Original Message- From: Richard Myers [EMAIL PROTECTED] It appears there is a majority opinion of those responding that we should start here, and perhaps move to another maillist in time. Someone suggested that a web page would be more appropriate, and I consider that a viable future option for archiving and eventually reaching a wider group. I will preface my posts with the phrase UNIX INTRO. This will allow uninterested users to skip these messages. I believe in teaching some background as well as basic UNIX concepts. I promise that we will soon get to the command line... Big snip This is exactly what we need. From the start, useful stuff. I often wonder why something works so I can tie the concept to the command and hopefully remember it next time. Memories are more easily retrieved if there are multiple connections in the brain, that is why multimedia is so exciting and important. At my Local LUG the gurus give long commands to the designated typist on a PC hooked to a projector so we can all see the display. After a long command we all ohhh and ahhh about the output and I ask why. It all starts to make sense when you know that 'ls' means list, 'cat' means concatenate, etc. Of course most people don't know what concatenate means but it is a word that can be looked up in a regular dictionary. Preach on brother. I'll be in class with my feet up and a maniacal grin on.
[newbie] UNIX INTRO
I would recommend newbies cruise the discount and closeout racks of your local B.Dalton and other bookstore chains. For $10, I got a copy of Dave Taylor's _Teach Yourself UNIX in a Week_. He gave us Elm, among other goodies, and he's an excellent writer. I've found the SAMS books particularly helpful. Lots of gems in those racks for a pittance. Check them out. Mark I believe in teaching some background as well as basic UNIX concepts. I promise that we will soon get to the command line... Big snip This is exactly what we need.
RE: [newbie] UNIX INTRO
Adding to this, 'Beginning Linux Programming' by Neil Matthew Richard Stones from WROX Press is good. Topics covered include: - shell programming - working with files - the UNIX environment - terminals - curses (ncurses these days I think) - data management - development tools - debugging - processes and signals - interprocess communication (pipes) - semaphores, message queues and shared memory - sockets - Tcl (Tool Command Language) - programming for X - programming for the internet (html) - internet programming 2 (cgi) I guess it just depends on whether you want to just rinse your face or get into it with the hipwaders on. hehehe -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of drek Sent: Thursday, July 29, 1999 12:50 AM To: [EMAIL PROTECTED] Subject: [newbie] UNIX INTRO I would recommend newbies cruise the discount and closeout racks of your local B.Dalton and other bookstore chains. For $10, I got a copy of Dave Taylor's _Teach Yourself UNIX in a Week_. He gave us Elm, among other goodies, and he's an excellent writer. I've found the SAMS books particularly helpful. Lots of gems in those racks for a pittance. Check them out. Mark I believe in teaching some background as well as basic UNIX concepts. I promise that we will soon get to the command line... Big snip This is exactly what we need.
