Book Review: A Practical Guide To Linux Commands, Editors, and Shell Programming 81
Rambo Tribble writes "This new, third edition of Sobell's book brings enhancements that add to the text's value as both a learning tool and a reference. This has always been a foundation book for those wanting a professional level of familiarity with Linux. The addition of chapters to introduce the Python language and MySQL database serves to offer the reader practical insights into additional Linux-related technologies." Read below for the rest of Rambo's review.
As the title suggests, this is a book about the Linux command line; GUI desktops are barely mentioned. This makes the text's primary audience computer professionals. As *nix professionals know, the command line not only offers quicker, more precise control of the system and its software, but is also far more portable across platforms. This is what allowed Sobell to extend his purview to encompass Mac OS X, in the second edition.| A Practical Guide to Linux Commands, Editors, and Shell Programming (3rd Edition) | |
| author | Mark G. Sobell |
| pages | 1200 pages |
| publisher | Prentice Hall |
| rating | 9/10 |
| reviewer | Rambo Tribble |
| ISBN | 978-0-13-308504-4 |
| summary | A concise, definitive guide for learning to manage Linux through the command line |
To be clear, this is not a volume to be taken lightly. It is a dense read, but is clearly written with concise and direct examples. In other words, it takes some concentration and effort to work through this book, but that effort is rewarded with a clear payoff of knowledge.
Sobell starts off by offering a basic introduction to Linux, exploring the roots of Unix and the evolution of Linux to become the mature and capable operating system it is today. Along the way, he delineates the aspects of the OS which define its character and form the basis of its appeal.
Next, he dives straight in to the particulars of running Linux from the command line. First, he outlines the CL environment and how to use it effectively. He is careful to point out the potential "gotchas" that can plague the uninformed neophyte. From there, he moves directly into the core commands, then the Linux filesystem and the shell environment. These subjects are at the heart of Linux system administration and while Sobell's treatment of them is necessarily brief, it is relevant and meaty.
In the book's second part, Sobell offers introductions to the most common editors to be found on Linux installations, vim and emacs. With a basic familiarity of how to edit text files, the reader is prepared to move into shell scripting, a powerful tool in controlling Linux and its suite of utilities and applications.
After a quick tour of shell environments, the author plunges into the common programming/scripting tools found on Linux, shell scripts, Perl, and Python. Once again, Sobell is obliged to brevity, but again he manages to provide a cohesive foundation that enables the reader to gain a good fundamental grasp of the subject, and a solid springboard for further learning.
The new chapter on Python introduces this cross-platform programming language, which enjoys growing popularity as a front-end development tool for Linux. Leveraging GUI toolkits, such as Qt or GTK+ , Python is considered by many to be the most effective choice for user-interface programming. The language is also commonly used in web server scripting. The Python coverage adds to Sobell's insightful treatment of the shell, shell scripts and editors already set forth in the volume.
The other new addition is a chapter on MySQL. MySQL has long enjoyed popularity as the "go to" database manager on Linux. Perhaps best known for being the "M" in "LAMP" web server setups, it is also commonly used as the back end for GUI programs, such as MythTV.
The coverage of programming tools wraps up with chapters on AWK, the pattern processing language, and sed, the stream editor. These essential tools of the command line provide useful data filtering and manipulation facilities.
The next section of the book is devoted to utilities providing secure network functions. OpenSSH and rsync are each given chapters which explore their capabilities in file management and secure communication use.
The command reference portion of the volume follows. Although it provides much the same information as the venerable on-line manual pages, it does so in a consistent voice with better illustrations and clear examples, something man pages are notoriously spotty on. Indeed, having Sobell's clear explanations, to compare, can be a great help in learning to interpret the often terse and sometimes arcane documentation the man pages provide.
Of course, 1150 pages, over a quarter of which is reference, doesn't leave time to repeat things or dwell in depth on any one topic. Sobell is often constrained to pages for subjects upon which numerous whole books have been written. With remarkable facility, however, he manages to clearly and directly convey the crux elements of each topic he addresses. This provides the reader with a broad and functional foundation in the basic elements of Linux/OS X system administration.
Bottom line: If you only get one book on the Linux command line and its tools, this should be it.
You can purchase A Practical Guide to Linux Commands, Editors, and Shell Programming (3rd Edition) from amazon.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
Re: (Score:2)
Re:Just In Time (Score:4, Funny)
Here's a book [amazon.com] more suited for the modern times.
Wait, why is this comment modded down?
Re: (Score:2)
Re: (Score:2)
Re:Linux = gay (Score:5, Funny)
Holy dog shit! Linux? ...
I just got the name of the new Distro I'm working on!
Re: (Score:1)
No big-breasted lactating lesbian links?
Thanks for making my bisexual wife cry!
Re: (Score:2)
Dude - you've got to get out of your private little fantasy world up there at Texas Instruments. I know that there are a lot of steers and queers along Interstate 35. But, that corridor isn't all there is of Texas. What are you guys using Linux for at TI, anyway? And, how did you teach the steers to use a computer?
Linux teaches! (Score:1)
Since taking up Linux and forcing myself to use it on the desktop, I've really gotten a good grasp of computer internals. It's awesome how Linux teaches you computer science as you use it to get work done!
IMO, it beats the crap out of any of those other dumbed-down "operating systems".
Its like that old saying (Score:3)
The burned hand teaches best. :)
Re: (Score:1)
Somehow I doubt it teaches you computer science...as the old saying goes, "Computer science is just as much about computers as Astronomy is about telescopes."
Don't confuse low-level OS details with computer science.
Re: (Score:3)
Since taking up Linux and forcing myself to use it on the desktop, I've really gotten a good grasp of computer internals.
To really learn about computers and digital technology, try this book: William Stallings - Computer Organization and Architecture Design (PDF, torrent) [malaysiabay.org].
Speaking of command lines... (Score:2, Interesting)
... off topic with regard to this book review, but maybe the right person will read this, so here goes. When using Terminal with caps lock accidentally on, I discovered that in Mac OS X (10.6 and 10.7 at least), 'CAL' will give you sideways output as opposed to 'cal':
Re: (Score:2)
Re: (Score:2)
Re:Speaking of command lines... (Score:4, Informative)
Sounds like your CAL somehow redirects in some cases to ncal - probably a bug in the filesystem.
It's so hard to tell if someone is trolling by making a backhanded swipe at a "feature" of OSX, or if they really mean what they say.
By default, HFS on OSX is case-insensitive (but is case preserving). So cal, Cal, and cAL all refer to the same program. It's not a bug.
Re: (Score:1, Insightful)
By default, HFS on OSX is case-insensitive (but is case preserving). So cal, Cal, and cAL all refer to the same program. It's not a bug.
It's not a bug, but it's a shitty choice made for dumb users. Utterly unacceptable for the UNIX environment. But then, OS X isn't UNIX for Apple users, it's a free OS Apple could nab and slap on a terrible GUI on the cheap.
Re: (Score:2)
By default, HFS on OSX is case-insensitive (but is case preserving). So cal, Cal, and cAL all refer to the same program. It's not a bug.
It's not a bug, but it's a shitty choice made for dumb users. Utterly unacceptable for the UNIX environment. But then, OS X isn't UNIX for Apple users, it's a free OS Apple could nab and slap on a terrible GUI on the cheap.
It's also the only Unix operating system widely embraced by users. So maybe it wasn't a bad choice after all. I can certainly understand why users wouldn't want to have to distinguish between mydocument, Mydocument, MyDocument and MYDOCUMENT.
Even as a long time linux/unix user, I never found a use for distinguishing files by case alone. Is there a legitimate use-case for that?
Re:Speaking of command lines... (Score:4, Insightful)
Case-insensitive but case-preserving is the smart choice. Amiga had this as well early on, then later Windows and several others. It means you can take files from Unix and they will just work; or files from DOS or ISO-9660 (uppercase only unless you had extensions), VMS, and they just work. Using the principle of least astonishment, I'd say this scheme is the logical one to use.
The only thing you lose from Unix here is that README doesn't sort before a.txt, and you can't have both Test.txt and test.txt in the same directory, but not a big loss.
Re:Speaking of command lines... (Score:5, Informative)
Debian will do this too if you manually create a "CAL" symlink and call that instead of `cal`, so I delved into the source for its Debian packge.
The code responsible is here [debian.org]. It prints in the horizontal format if you call the program as "cal" (case-sensitive), and in the vertical format otherwise. I have no idea why it does this (the git repository only goes back to 2009, and I bet this code has been around for a lot longer than that), but there it is. On my Debian system, the program is installed as `ncal`, with `cal` being a symlink to `ncal`, so perhaps the vertical mode is the intended format and the horizontal mode is for backwards compatibility with a previous `cal` tool?
OS X systems are case-insensitive by default, so your attempt at using `CAL` ended up running ncal via the `cal` symlink, but the check for calling name is case-sensitive, so the horizontal mode isn't triggered.
Re: (Score:3)
so perhaps the vertical mode is the intended format and the horizontal mode is for backwards compatibility with a previous `cal` tool?
And the answer is in the most obvious of places. From the cal manpage:
The cal utility displays a simple calendar in traditional format and ncal offers an alternative layout, more options and the date of Easter. The new format is a little cramped but it makes a year fit on a 25x80 terminal.
and
HISTORY: A cal command appeared in Version 5 AT&T UNIX. The ncal command appeared in FreeBSD 2.2.6. The output of the cal command is supposed to be bit for bit compatible to the original Unix cal command, because its output is processed by other programs like CGI scripts, that should not be broken.
Naturally I went and found FreeBSD's archived copy of cal [freebsd.org] (which does indeed print in horizontal format, and was replaced with ncal in 1998) before I thought to look at my own system's manpage.
gcal does sideways format with actual flags (Score:2)
not sure about OS X, but gcal (from GNU) lets you add --type=special (or the "-i" flag). I'm pretty sure you could implement what you find with a shell script looking at $0. So, seems handy, but just a curiosity, I'd say.
Re: (Score:2)
... off topic with regard to this book review, but maybe the right person will read this, so here goes. When using Terminal with caps lock accidentally on, I discovered that in Mac OS X (10.6 and 10.7 at least), 'CAL' will give you sideways output as opposed to 'cal':
Does the same thing on Ubuntu 12.10:
$ ln -s
$
March 2013
Su 3 10 17 24 31
Mo 4 11 18 25
Tu 5 12 19 26
We 6 13 20 27
Th 7 14 21 28
Fr 1 8 15 22 29
Sa 2 9 16 23 30
Which is the same as running "ncal".
Looks like /usr/bin/cal is a symlink to /usr/bin/ncal, so the cal/ncal program must look to see if it's been invoked as "cal" and if not, then it treats it as ncal.
$ ls -l
lrwxrwxrwx 1 root root 4 Jan 19 00:52
Re: (Score:2)
I have a command line utility for this, called tilt (maybe a google
for tilt-1.0.tar.gz or tilt-1.0.tar.gz still works?).
The itch it scratched was that I needed it at the time I was creating
crossword puzzles and needed the ability to rotate a diagram in
order to easily create the descriptions for vertical.
If you can't find it, lemme know.
tilt-1.22.tar.gz (Score:2)
Here it is:
http://bjdouma.home.xs4all.nl/tilt-1.22.tar.gz [xs4all.nl]
Re: (Score:1)
The second is ncal output.
Re:Speaking of command lines... (Score:4, Informative)
This book should be up-to-date for a few years (Score:5, Informative)
Re: (Score:2)
It's unix CLI that really does not change much. One of windows biggest issues if they have to change everything each generation as a sales tool.
Re: (Score:1)
One of windows biggest issues if they have to change everything each generation as a sales tool.
Compare apples to apples. Either compare GUIs -- in which case many Linux GUIs make substantial changes with some frequency (e.g. Gnome Shell and Unity), though many don't -- or compare CLIs -- in which case the Windows CLI has seen a comparable amount of development since the days of DOS. (You could look at PowerShell on the Windows side, but (1) that's still only one big change in 25 years, and (2) PowerShell
Re: (Score:1)
PowerShell is actually pretty awesome.
Yep, pretty awesome [briancarper.net] alright.
Re: (Score:2)
Ha, "ripoff of bash". As if sh, csh, or ksh never existed...
Re: (Score:1)
Ha, "ripoff of bash". As if sh, csh, or ksh never existed...
Plus the fact that anyone who says that PowerShell is a ripoff of the traditional Unix shell either (1) doesn't know anything about PS, (2) doesn't know anything about sh, or (3) is smoking something pretty darn strong.
Re: (Score:2)
Re: (Score:2)
Anyone who's used BASH for any amount of scripting knows how useless PowerShell is as soon as they play with it.
Re: (Score:2)
Re: (Score:1)
I am interested in CLI books too, but very few of them reveal how powerful the standard commands are.
My favorite beginner's book is "Understanding Unix" by Stan Kelly-Bootle, now out of print. While most Unix books remained reference books for individual commands, SKB's book showed how to stitch commands together, creating scripts that did neat stuff for a beginner (like producing a table of the most frequently used words in a text file) using humble Unix/Linux commands. I have looked at several books on th
Re: (Score:2)
I have an ancient version of this book (same author) from back in the 1980s when it was called A Practical Guide to Unix System V from and it's still pretty useful...
great (Score:4, Informative)
expect (Score:4, Informative)
Users should be aware of another tool that can be used under GNU/Linux, it's called 'expect'. While normal shell programming is extremely useful and powerful, 'expect' provides a mechanism to 'talk' to interactive programs while running a shell script. 'expect' will actually expect certain known points of interaction from an interactive command line program and will provide it with input as if a user typed it by hand.
It's useful for example to code update procedures with expect if you have more than one machine to administer and you have to update something on the machine, maybe update a package or two, run some database commands, do it all from your machine over ssh without having scripts installed on the machines on the other side, things like that.
Re: (Score:3)
the udachny account is a sock puppet of roman_mir. do not encourage his sock puppetry by moderating it up.
I don't think any account associated with roman_mir would be able to make a post without referring to the evils of government, regardless of the subject at hand.
Sold. (Score:1)
Does anyone read books like this anymore? (Score:1)
I mean 1200 pages? If I can't do something I look online rather than have my desk cluttered by a few 1200 page manuals. In a storage box somewhere, I still have the Microsoft Visual C++ 1.5 set, which occupies an entire freaking bookshelf. I think that was the time when I realised paper documentation was going to die.
Re: (Score:1)
Not sure if I should be glad or ashamed: I also have the entire MSVC 1.5 doc set, along with the full MASM 6.1 doc set, in a bookshelf behind me. Yes, it's two full shelves of old dead trees. Haven't touched those book since '96, but there they still are. And both you and I have 5-digit UIDs.
The rest of you: get the hell off my lawn, dammit!
I like Sobell's books, I have a number of his and Kochan's book going back years. Always very well-written books. But for 1200 pages, I'll wait for the PDF.
Re: (Score:3)
The printed page comes in handy as 'bathroom' reading material, especially when stumped by a problem that can be solved with a few lines of script. One can then do half of the research online because you can only spend so many hours gazing at the screen. My linux book became dog-eared even after the CD it came with became obsolete, but I learned to appreciate having root as a second user instead of a sudo byword.
This could lower the signal-to-noise ratio by uncluttering the forums; I see many n00bs still be
Re: (Score:3)
Its often very handy to have a list of commands or features or api references that's easy to search. Meaning Google is a bit too large a tool, but something like a BASH quick-reference is very handy. I can't imagine this not being a digital reference though; paper seems so redundant.
Re: (Score:1)
You must be lost. This isn't Digg.
Re: (Score:2)
Re: (Score:1)
Your wife had 0 problems finding a practical use for something quite big.