This is a repost of a review that is timely, given this week's focus on setting up your Linux server and changing all your computers over to Linux and so on.
For the most part, computer operating systems all have a "shell." When people talk about the "command line" ... they are talking about the prompt in a shell. The concept of a shell, and the way we think of a shell today mostly stems from its implementation on Unix systems. A shell is a computer program that has a human interface and a number of built in or accessible functions (mostly other programs) that humans can invoke to make the computer do something. On 'servers' and on most computers back in the old days, the shell would typically appear as a prompt on a computer screen, and that would be all you would get. You type stuff in, and the computer types stuff as well, and between the two of you, stuff happens. On a computer with a graphical user interface (GUI), there is still a shell, but it looks different. The shell is less tangible to the human user, but the GUI itself is a program that provides the user interface, and it may either be the shell itself or it may be invoked automatically as the computer starts up by the shell.
Back in Windows 3.X days, the shell was called "Win" and there was a file on the computer that said, somewhere, "Shell=Win" or words to that effect. A neat trick to compensate for the fact that even then Windows was over-demanding of valuable hardware resources (memory and stuff) was to change this line so that it said "Shell=Word" ... this was useful if you only wanted to run Word .... the windows desktop would not load, and thus not be using up resources. (Of course, you could run other programs by invoking them from within Word.... ah, the old days.)
One of the earliest Unix-type shells was called "sh" for "shell." There were various shells, and for a time, shells competed with each other for dominance. At some point, I'm not sure how far back (maybe forever) a neat convention was worked into Unix/Linux systems such that if you invoked a shell different than the one you were using ... like, if you wanted to run the korn shell and you were in the sh shell ... you would just type the name of the new shell and that would replace, rather than run as a sub process in, the old shell. That is probably the least important thing you are going to learn today. Or all week, for that matter.
Somewhat more relevant is this question: What is the "BASH" shell? Well, there was a shell born of sh that was, and still is, called "Bourne" after it's inventor, Stephen Bourne, in 1978. (No relation to Jason.) Later, yet another shell was developed based on Bourne, but better. Born of Bourne through the efforts of Brian Fox in 1987, the new shell was called "Born Again Shell" ... or, for short, BASH. BASH was written as part of the GNU project, and is thus one of the key pieces of software that runs on Linux systems.
People will argue about this, but BASH is probably the best shell, the most modern shell, the coolest shell, for use in Linux. If you are going to learn how to use a shell, this is the shell to learn. In Ubuntu Linux, if you start a terminal, it will typically be a BASH shell that runs.
Learning the bash Shell (In a Nutshell (O'Reilly)) is an excellent, highly recommended introductory volume on BASH. It is one of a number of books that I would recommend for anyone who wants to learn BASH. Many parts of this book are too rudementary for many who would have an interst ... chances are if you want to learn bash programming, you probably already know enough to be slighly annoyed at a very introductory book. However, it also may be true that you have not been systematic and thorough in your coverage of bash. So, I recommend this book to anyone who cannot answer he following questions:
What is a path, where is your path stored, how do you change it on the fly, and how do you change it permanently?
How do you take a text file full of shell commands and make it into an executable file that you can run any time you want from the command prompt?
What is a 'select' command and why is it cool?
Considerer the following bash program:
if [-a $filename]; then
1) What is wrong with the syntax of the second line? (Hint: The programmer has spaced something out)
2) What will this program do?
3) Why does the third line say "exit 0" and not "exit 1"?
If you know the answer to all of these questions, then you probably don't need this book. If you know the answer to none of these questions, then you probably need this book. If you fall in between, then, well, that's a tough decision.
Suck it and see ...
... Experimentation always leads to the truth
Bash is the bomb.
The single most important thing I posess is my .bashrc file and my own personal bin directory of scripts I've collected over the years. I have a small area of working memory so I always forget where things are. So I wrote BashBM, short for BashBookMarks. It lets me just type 'mark here' while cd'd to a directory and then later type 'goto here' and it'll take me back there.
Anyway, Bash rules. The first thing I do on any Windows system a job gives me is to install Cygwin, just so that I can have my beloved Bash, grep, sed, awk et al.
I've been using tcsh since about 1986, when it became available on the Amiga. For years, I've been thinking I should learn to use Bash, just because it's the de facto standard. I've been able to keep putting it off because there are enough similarities among shells that a user who's proficient in one can figure out what to do in others. But to use Bash in the most productive manner requires attacking a learning curve. That O'Reilly book is looking more like a good idea every time I run into it.
John, you may get more out of a more advanced book. Check out "Classic SHell Scripting" here: