Books on use of Linux command line
 

Can someone please recommend a book and/or website that gives a clear and basic explanation of how to use the Linux command line? I know that the real power of Linux resides in knowing how to skillfully use the command line and not having to rely on the GUI platforms. Many books I've looked at assume a substantial amount on the part of the reader and don't give the kind of basic explanations and instruction I am looking for. If anyone knows of such a book, I would sure be grateful! Thanks in advance!

Hi,

how to use the Linux command line can mean many things, maybe you are looking for guides like these?

- GNU/Linux Command-Line Tools Summary
- Introduction to Linux - A Hands on Guide
- Bash Guide for Beginners

All the above can be found at this site: The Linux Documentation Project (LDP)

And a link to O'Reilly's Linux in a Nutshell - Commands List

Hope this helps.

Thanks for the above. I shall look into these sources. Here's what I'm after: many guidebooks for Linux are basically just a fleshing out of the man pages. That may be fine for someone who already knows something about command line use, but for a novice it doesn't explain what those terms mean in the sense of how they're to be applied. When you are looking to understand a foreign language, you want something more than a long list of vocabulary words. Vocabulary is no doubt central to knowing a language, but you also have to know how to apply it--putting those words together to form an intelligible sentence. And of course there you get into syntax, verb tenses, use of colloquial expressions, etc. Using the command line is learning a language, of sorts, and it's difficult for the beginner to know where to start. I'm very interested and so have the desire to learn, but it's hard to escape the feeling that I'm sinking in quicksand with nothing to grasp onto! Is there a source that addresses the need for basic building blocks and a foundation that a novice like myself is seeking? Hope this clarifies.

Hi again,

The first 2 links I posted are probably what you are looking for.

The third one (Bash Guide) is an introduction to writing shell scripts. Do have a look at that one as well. Your command line life will become so much more pleasant if you know how to use the shell, awk and sed.

All off them have chapters based on specific theme's and have command/concept explanations with examples and possible tips and warnings.

Hope this helps.

Thanks for your helpful points. On the subject of shells, a friend of mine strongly endorses KornShell. He likes it because he says it's actually inclusive of many Bash commands but also goes beyond it. I realize Bash is the default on most Linux systems, but you can easily switch to KornShell. As far as learning shell scripting, do you think ksh is a good option? (There are good books on ksh as well.)

Hi,

As said by you: I realize Bash is the default on most Linux systems. Ksh was/is used a lot on Unix systems. I would go with bash on Linux. Modern day bash versions are as good as ksh in my opinion.

If you do install/use ksh you need to know that there are a few ksh flavours out there (ksh93 and ksh88 based), they are not the same!

Besides the bash guide for beginners I posted there's also this link: Advanced Bash-Scripting Guide

Hope this helps.

Can you explain what the difference is between working at the command line and working with the shell? My understanding is that shell is the way the user communicates through the hardware to the kernal of the os. So how is it different from the command line itself? Your answers are appreciated!

Here's a good tutorial
http://rute.2038bug.com/index.html.gz

covers concepts as well as actual cmds.

cli vs shell; no difference, just terminology.
When you type into the cli, you are talking to the shell eg try 'echo $SHELL'. Usually bash on Linux. On commercial *nix eg Solaris, HP-UX, AIX etc, the default is usually ksh.
However, these days you can often choose which one you want.

Very useful replies! It seems like most of these sites are complete books. Is it recommended to read through these things in their entirety, or just selectively? If the texts are well written and thought through, I would guess there is a sequence to how the concepts are presented and so it's best to read it straight through. I appreciate these very helpful suggestions! If any others come to mind, please post them. Working with this material is a bit intimidating at first, and any learning aids you can find make the process more manageable.

Well, for the Rute Tutorial, yes, just start at the beginning, go on to the end, then stop :)
Basically, its time to stop asking qns and start doing ie work through that tutorial, don't just read it, it won't sink in.
If you get stuck you can always ask specific qns and/or check the other refs....

Here's another one, a free downloadable .pdf:
http://linuxcommand.org/tlcl.php

I appreciate these very helpful and encouraging replies! Good point about just plunging forward! It's just that this is new terrain for me and much of it seems overwhelming. But thanks so much for the references!

Remember that "the command-line," that is to say, "the shell," is simply a way of executing some program (or some built-in command) by typing its name along with zero-or-more parameters. When you "click on an icon" in a GUI, you are really doing the same thing even if you don't know it.

All of which leads me (somehow...) to an attempt to set the topic of "scripting" into proper context...

When you "execute a command," by any means, the shell looks at the content of the command file and tries to "cause it to happen." It looks at the first few bytes of the file to determine whether it's an executable program or a script of some kind. In particular, it looks for #!program_name ("shebang") as the first few characters. There are essentially three possibilities:

1. If the file is an executable program, it is executed.
2. If there is a "shebang," the specified program is invoked to execute it.
3. Shells usually have some kind of built-in scripting capabilities. Bash has less; Korn shell (ksh) has much more.

Most significantly, you can't tell the difference between any one of these three methods.

Thus, "here, we have the command-line shell," and, "over there, we have scripting." Furthermore, "when we talk about 'scripting,' there are quite-literally many dozens of choices, of which the built-in capabilities of the shell itself are only one." Perl, Python, PHP, Ruby, Lisp, FORTRAN, COBOL, Prolog, Ada, several BASICs ... many more. All of them available for use, all of them available free-of-charge, and from the user's point-of-view, all of them absolutely indistinguishable. Probably the most important feature of the Linux/Unix programming environments is the richness of the tool-set that they all offer to the programmer and to the user, and the simplicity with which they can be invoked and combined.

Categorically speaking, I would in fact downplay the use of "shell" scripts, because when you have so many purpose-built full-blown programming languages at your beck and call, it seems to me to have little point to try to constrain yourself to what a (bash...) shell can do, and (although I know Dr. Korn would disagree with me) it does not seem quite the place to put a programming-language into a shell.

"The command line" is ... one way to do it. Not the only way, and in any case it is simply a means of expression. When you link an icon to a file, or to a command, within any Linux GUI, you are in fact doing the same thing, and your possibilities are (as I have described) "virtually unlimited" in both scenarios.

:) Once you start digging beneath the surface of Unix/Linux, and you hit this massive vein of pure-gold that you never knew existed (because you weren't obligated to dig if you didn't care to) ... then you know in a flash "what all the fuss is about!"

sundialsvcs! This is one of the clearest, most succinct explanations of the command line/shell that I have ever seen! If you haven't yet written your own book, you certainly should. You might want to title it, "Understanding Linux," because this is what novices are struggling to do. Over and beyond learning the requisite commands, you need to understand the concepts behind what it is you're doing. In the three possibilities for shell commands I'm not clear about nos. 1 and 2. I understand "1" but what is the additional feature about "2"? "3" I understand is the scripting capability.

If, as you say, "it seems to me to have little point to try to constrain yourself to what a (bash...) shell can do," then why do you go on to say, "it does not seem quite the place to put a programming-language into a shell"? If you're not going to confine yourself to bash (or whatever) why wouldn't you resort to other programming languages? I have a friend who lavishly sings the praise of Korn shell because of its portability and speed. What I gather from your comments is that when you are working with Linux, the beauty is that there is a seamless connection between executing programs and "scripting." It's not like you have to go out and learn an entirely new language so that you can proceed to write script--the language used to execute commands is the same as what you use to write script. (Is there any continuity between different scripting languages? Although they are different, are the common patterns such that learning one makes it easier to learn a second and third? Or are they all entirely different?)

But this takes me far afield from where I'm presently at. I just need to learn to feel comfortable with the command line. Initially, I'm not going to do anything that fancy--I just want to be able to execute commands that I have up until done through the front-end material. It seems like the references already cited on this post are a good starting point. Thanks!

Re your qn on "1,2,3":

Basically there are 2 kinds of program files you can 'run'

a) binary (ie compiled+linked) executables eg derived from C, Fortran, COBOL src code
b)'src code' langs eg any of the shells and also Perl, Python etc.

The latter may start with a 'shebang line eg
in which case you can call them direct eg
If the shebang line is not there, you can invoke the relevant shell externally thus
Note that I'd disagree with your friend re ksh being fast; all shell langs are interpreted that is to say each shell script line is re-parsed (translated) into the relevant machine code each time it's called.
Contrast this with compiled exes (eg C progs) which are already in machine code. These are orders of magnitude faster.

Note that Perl is kind of a half-way house; you only write a Perl program as src, then invoke it. However, the first thing the actual system perl prog eg /usr/bin/perl does is read your perl file and (loosely speaking) compile it on-the-fly and run the 'compiled' version in RAM. This means its eg 80-90% as quick as C.
See http://www.perl.com/doc/FMTEYEWTK/comp-vs-interp.html for the gory details.
No idea if Python, ruby do this; they may well ...



As you say, the 'shell' you write individual cmds in to talk to the OS is the same one you can collect repetitive cmds into a file and run as a program.
This makes perfect sense. However, what sundialsvcs is alluding to is not to over-do it.

Basically, automating a process is fine, but if you are going to be writing anything non-trivial, then use a 'proper' programming lang eg Perl or C.

Knowing where to draw the line is subjective. Personally anything fiddly or long-winded, I'd use Perl.
Short stuff in bash (Linux) or ksh (Solaris, HP-UX).