Practical Guide to Linux Commands, Editors, and Shell Programming

Author: Mark G. Sobell
Format: Paperback, 1080 pages
Publisher: Prentice Hall PTR; 2nd edition (November 29, 2009)
ISBN-10: 0131367366
ISBN-13: 978-013136

The reviews on the first edition of this book were overwhelmingly favorable, so you'd expect Sobell's second edition to be at least on par. What I want to know before handing over my hard earned green, is why I should buy the second edition? What has changed so much in the world of Linux in 4 or 5 years that makes a difference? With those questions in mind and tome in hand, off I went in pursuit of the answers.

The back cover blurb touts the advantages of this book, including the fact that it includes both system administration info and programming data; material that is usually archived in two different books (with the idea that system admins and programmers don't live in the same universe). Another advantage is that the book is "distro agnostic", meaning that it doesn't favor Ubuntu and other Debian-esque flavors vs. Fedora and other Red Hat variants. Surprisingly, though I suppose it shouldn't be, info on Mac administration is also included (and why not...go back far enough and the common ancient ancestor is UNIX). But what's new?

Gold dust was discovered in the Preface in the New in this edition section. Turns out, Mac OS X CLI info is brand new in this edition, so if you love Linux and Mac, or at least you have to administer them, you're in luck. Also, there's a new chapter on Perl, new rsynch secure copy utility material, and content covering 15 new utilities that weren't included in the first edition. There have also been some organizational changes. Three indexes have been added to make it easier for the reader to find specific information, including an index just for Mac OS X.

The first five chapters or so bring the reader up to speed on Linux and Mac (mostly Linux) in general, including a basic overview of the operating systems and where to find things. Common utilities, file system basics, and an introduction to the shell are all available. Up to this point, you don't have to be much of a guru in anything or even much of a power user, so students who want to be admins and shell programmers are welcome here.

They say there are two types of people in the world; vi people and emac people. I happen to be the former but understand (reluctantly) that there are plenty of folks out there that prefer the latter editor. Sobell serves both populations with a chapter devoted to each editor. Keep in mind there are entire books written on these editors, but you may not have the desire or time to buy and read them.

The book then moves the reader on to more detailed information on the shells. The bash (bourne again shell) shell is included as well as the TC shell, which is the expanded version of the C Shell (csh and yes, it's pronounced "sea shell"). I've never worked with a Linux system that didn't have the bash shell as the default, but if you really want something "completely different", here's your opportunity to learn about the TC shell.

The next part of the book: "Programming Tools" includes some of the main changes in this edition. The brand-new Perl chapter is inserted here, as is the chapter on rsync. Don't expect to learn Perl from scratch by reading a single chapter in this book, but if you have a background in Perl or just in general scripting, it will help in Linux shell programming. My personal preference is Python, but you can't have everything.

The last main section is the command reference and it is basically a long list of man pages. The twist is that some of them (they're marked) are commands specific to Mac. I'm not sure if it would be faster for the experienced Linux user to just read a man page in the shell or to look it up on Sobell's book, but they're here, anyway. That said, there are additional details present, as least for some of the commands, including examples, discussion areas, and the occasional diagram you won't find on a man page.

I probably could have lived without the Glossary in the Appendix section, but if the book is supposed to speak to newbies as well as power users and admins, then it makes sense. As I previously mentioned, one index includes nothing but Mac OS X notes, which is a nice plus, but I suppose it assumes you're working in a mixed Linux/Mac environment. If you administer just Macs, I can only imagine you have the required Mac-oriented texts on your bookshelf.

The main advantage of this book and others like it, is not that it contains any radically new information or that it's put together in a unique way. The reason you want to buy this book is that all this information collected entirely between two covers. The entire body of Linux administration data is more or less easily located on the web and is no more than a search string in Google away, but the Internet is a lousy library. By comparison, Sobell's Practical Guide to Linux Commands, Editors, and Shell Programming is a model of organization.

The second edition of this successful book does what it's supposed to; update information for a changing technology landscape, add a few new bits for spice, and otherwise maintains the original level of quality. You could read it cover-to-cover, but something this size works better as a reference for the learner or the experienced person who needs a quick reminder (you can't remember everything). If you administer Linux, program Linux, or both, this book most likely has what you need. If those roles are your goals, then this book will carry you to the target. Enjoy.

You can find and purchase Mark Sobell's book at Amazon.com.

Wiredwriter.net has Changed

I've never mentioned my original website on this blog before, mainly because it had aged badly and I never found the time to pay any attention to it. That all changed a day or so ago and I got the bug to completely revamp it. Fortunately, I decided to lean towards the simple side of things. The site has a temporary home on a small server appliance sitting on my desk, but I'll eventually let it live at a proper web host.

Reintroducing Wiredwriter.net. Let me know what you think (and I haven't forgotten about the programming tutorials...maybe over the holiday break, I'll do more).

Why Hasn't Google Wave Gone Viral?

I received an invitation to get Google Wave and, with serious intent, decided to give it a whirl. After all, I had initial misgivings about Facebook and twitter, but now you can't blow me off of either one with a stick of dynamite. I figured (reluctantly...how many ways to communicate do I really need?) that Wave would be the next big app in my life to consume what little time I don't have. I even wrote a review on Wave a few weeks ago, so I was on my way, right? Wrong. What happened?

I logged into Wave for the first time in three days this morning and found a "wave" from someone making the same statement I just did. She said:

I know! That's what's "un-useful" about it - I always forget to check mine to so I just revert back to Twitter and email - you know - those "oh so out of date" tools! ;-)

I don't get it. I remember when Gmail was "by invitation only", and now every one has Gmail and I use it as my default webmail. I've pimped my Google home page with a customized theme and all manner of gadgets I use to keep track of my social networking. Google has me hooked as far as that part goes, so what's the problem with me extending my "addiction" to Wave?

The question that seems to come up from the people I do use Wave with is "what am I supposed to use this thing for?" I managed to add about a dozen people to my Wave address book, but conversations have stalled. I've started following a few public Waves to see if I could join in on a conversation, but they're hard to follow. Nothing seems linear. When a new contribution has been made to a Wave, it isn't at the top or bottom of the stream as you'd expect (as in a "conversation" in Gmail, for instance), nor does the Wave automatically focus on the new addition.

I think part of the problem is in trying to find information to make practical use of Wave. For instance, in attempting to do the research for this blog, I did some Google searches (what else?), but searching for "why hasn't Google Wave gone viral" doesn't yield a great deal of useful data. I managed to locate the article Why We Are Cautious About Google's Wave, but frankly, it didn't do much to answer my question. It was written soon after Wave was first introduced, so the information has "aged" somewhat (at least in Internet time).

Next, I tried searching Wave itself. I figured if anyone would be talking about the use of Wave, or lack thereof, it would be Wave users. Am I wrong? Facing the Wave UI, I realized I'd forgotten how to search for public Waves. A little Googling later, I found The First Google Wave Search You Must Know and with a mere with:public, pulled up an endless list of public Waves. Gee, how unique. Now how do I find the one I want? I don't want to read a book and I don't want to scan a 14 page web guide. Like most people in our Microwave oven, Google search engine, instant gratification world, I want to ask a quick question and get a quick answer.

I don't remember having this sort of problem getting on board with twitter, and realistically speaking, I haven't been using twitter all that long. Sure, Tim O'Reilly and Sarah Milstein wrote The Twitter Book, but I didn't use it to "learn twitter" (it actually wasn't a really great book, and I ended up donating it to my local public library after reviewing it). When I needed to know something about twitter, I either asked another twitter person or Googled it. I usually found the little tidbit I needed (who has time to read a whole "dissertation" like this blog?) and away I went.

I have an interest in Microsoft's SharePoint platform (don't ask...it's a long story), and am following a few public Waves on the topic. This is a frequently asked question: "Is Wave a SharePoint killer?" and the general consensus is "no" (despite Om Malik's prediction in his previously mentioned blog). Sure, Wave is extendable with just oodles of APIs, but in what direction does one "extend" Wave to make it usable and (dare I say it) intuitive? Why does it seem so hard to use Wave?

It occurred to me that either Google never intended Wave to be particularly useful to the average end user crowd, or they initially targeted the wrong audience. Speaking of SharePoint, I find myself wondering if Wave is intended (or should be intended) for the business, rather than the general public space? Everything else is going into the cloud, why not enterprise collaboration? This seems to be the thought of David Cook at The Shiny Wave blogspot. Perhaps my failure to launch, relative to Wave, is due to my being the wrong person to use it, or at least my using Wave in the wrong context.

Of course, I've tried Delicious, Friendfeed, Plaxo, Plurk, and other online social apps and promptly walked away, not feeling "the hook" sink deeply into my flesh, so maybe Wave is just another passing fancy that didn't take hold in my life. Then again, I didn't bother to review any of those apps and or dedicate two (so far) blog articles to them, so Wave must have made some sort of impression on me.

It can't be lack of information. Doing a general search on Google Wave produces a ton of results, including guides at Mashable and Lifehacker, so quality tech affectionados feel Google Wave is worth spending time and resources on. On the other hand, getting a specific piece of information seems excessively difficult, such as how to find a specific public Wave discussing why Wave hasn't "gone viral", so is that it? What's the problem? Is it Wave or (gulp) is it me?

Afterword: I just added a public wave: "Why Hasn't Google Wave Gone Viral" and made it accessible to everyone (Thanks for the tip, Google). Let the games begin.

Human Rights Day: Free Gilad Shalit

I saw a "tweet" on twitter originally posted by Nonprofit Orgs and retweeted by Pursue Compassion announcing Human Rights Day and promoting the Have Fun, Do Good blog. I spent a little time reviewing the list of rights being promoted, but didn't see one that said "The Right to be Released from Illegal Captivity". I know that Amnesty International generally champions the cause of political prisoners, but I wasn't sure they included Gilad Shalit in their list.

According to Wikipedia, Gilad Shalit is an Israeli soldier who was captured by Palestinians during a border crossing raid on June 25, 2006. He was just 19 years old at the time and has been illegally held by the Palestinian terrorist group Hamas for almost three and a half years.

On February 10, 2009, Hamas released a video of Shalit showing a gaunt but otherwise apparently healthy young man. Hamas required the release of 20 female Palestinian prisoners just for making the Shalit video available to the Israeli authorities and the world media. While there has been recent news of an "imminent" release for Shalit, most likely mediated by Egypt, there have been no tangible results. Each side says that the other is to blame, according to a December 3rd news story by the Christian Science Monitor, but in the end, this 23 year old man is still in the hands of terrorists, with no end in sight.

Hamas generally demands the release of a large number of prisoners from Israel in exchange for a single Palestinian captive. There's an unconfirmed story online stating that Israel has agreed to release almost 1000 terrorist prisoners in exchange for Shalit. Whether this is true or not, it's understandable that Israeli authorities would balk at putting such a large number of terrorists back on the street to do more harm. On the other hand, if Israel levies sanctions on Gaza, where Hamas is headquartered and where Shalit is being held, "world opinion" is likely to again paint Israel as aggressive and hostile in their response, and said-response could include withholding food supplies and electricity from Gaza and even a military solution.

This last viewpoint of the world towards Israel is especially puzzling on Human Rights Day. Gilad Shalit is a human being. He has the same rights as any other human being. He is being held against his will. He committed no crime. He is NOT a prisoner of war, at least as evidenced by Hamas and their total and complete failure to comply with the conditions for the treatment of prisoners of war as per the Geneva Convention. Putting a rather fine point on the situation, Gilad Shalit is in the hands of a criminal gang whose sole purpose seems to be the extermination of the Jewish people.

In the spirit that Britt Bravo has attempted to create with her Have Fun, Do Good blog, I have taken up a cause. She encourages each person to do something to promote human rights, such as "Write a Letter, Make a Video, Embrace Diversity" for Human Rights Day on December 10th. For the occasion, I'm writing this article on my blog. I don't know that it's "fun", but I believe I am doing good. I'm embracing the human rights of Gilad Shalit, held captive illegally by Hamas in Gaza for 1264 days as of this writing. Gilad Shalit is a soldier, an Israeli, and a Jew. He's also a human being. Promote his human rights. Free Gilad Shalit! Free him now!

What do Interpreted Programming Languages have in Common? Part II

I begin this tutorial a few weeks ago with Part I and received some very nice comments correcting my (fortunately) minor errors. This isn't a tutorial about how to program in a specific language or even really about how to program. I wanted to show the common structure of interpreted programming languages in the hopes of revealing some common threads, rather than focusing on the ins and outs of one language. I've heard it said that if you learn one langauge, it makes learning the next one easier. My problem is I get lost in the nuances of the language in question and lose track of the basic structure of programming. I've created this tutorial series to try and correct that. This tutorial is for my education as much as anyone else's so I welcome comments but, as I said before, be polite. This is about learning.

Speaking of Languages, code examples are presented in JavaScript, Python, and Ruby. I figured this represented a healthy cross-section of commonly used interpreted languages. Now, on with the show.

Controlling Program Flow, Part I

In our last episode (sorry, couldn't resist), we left off with Arrays and Booleans. The tutorial picks up with methods of flow control. According to Wikipedia, flow control is "a statement whose execution results in a choice being made as to which of two or more paths should be followed. For non-strict functional languages, functions and language constructs exist to achieve the same result, but they are not necessarily called control flow statements." In other words, it's a way of making decisions within the program given different conditions. Speaking of which:

Conditions: These statements in a program act as a decision tree or like a set of intersections in a city. The decisions or route are dependent on what conditions are or are not true (speaking of Booleans) or where you're trying to go. The basic structure of a conditional statement looks something like this:

if (condition)
{
     conditional code;
}

That's a very general example, of course, but it gives you a place to start.

if statements:
If statements are more or less the same in all three of the languages we've been working with:

JavaScript Sample Code:

var value = 0;
if (value > 0)
{
     alert("Greater than zero");
}

Python Sample Code:

n = 0
if n > 0:
     print ("Greater than zero")

Ruby Sample Code:

n = 0
if n > 0
     return "Greater than zero"
end

Of course, that's not much of a decision tree. Each program has different conditional statements that are similar but not exactly the same, to deal with a decision that is either this or that:

if-else statements:
The following examples are equivalent and look almost the same, but not quite:

JavaScript Example Code:

var name = "Jim";
if (name == "Jim")
{
     alert("Your name is Jim.");
}
else {
     alert("You are not Jim.");
}

Python Example Code:

name = "Jim"
if (name == "Jim"):
     print ("Your name is Jim")
else:
     print ("Your name is not Jim")

Ruby Example Code:

name = "Jim"
if name == "Jim"
     print "Your name is Jim"
else
     print "Your name is not Jim"
end

That takes care of "the fork in the road", so to speak, but what if there's more than one decision to make? It can't be just "Jim" or "no Jim" all the time. What about Jim, Bill, and Heather, for example?

else-if statements:
Depending on the program, this statement is called else-if, or elif, or elsif, but you get the idea.

JavaScript Code Example:

if (name == "Jim")
{
     alert ("Good Morning, Jim.");
}
else if (name == "Bill");
{
     alert ("Good Morning, Bill.");
}
else if (name == "Heather");
{
     alert ("Good Morning, Heather.");
}
else
{
     alert ("You're not on the list.");
}

Python Example Code:

if (name == "Jim"):
     print ("Good Morning, Jim.")
elif (name == "Bill"):
     print ("Good Morning, Bill.")
elif (name == "Heather"):
     print ("Good Morning, Heather.")
else:
     print ("You're not on the list.")

Ruby Example Code:

if name == "Jim"
     return ("Your name is Jim.")
elsif name == "Bill
     return ("Your name is Bill.")
elsif name == "Heather"
     return ("Your name is Heather.")
else
     return ("You're not on the list.")
end
print name

As you can see, there really isn't much difference between now each language expresses conditional statements. The details are quite minor and I hope this all illustrates the common factors in such statements, which is the important piece to learn in this lesson.


Time limitations are forcing me to make Part II shorter than I originally intended, but at least I've got it up and on the blog. Pick through everything and see if I left any holes. If so, let me know. If not, then all is good, at least for Part II. See you next time for Part III: Loops.