Forgot your password?
typodupeerror
Image

Book Review: A Practical Guide To Linux Commands, Editors, and Shell Programming 81

Posted by samzenpus
from the read-all-about-it dept.
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.
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
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.

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.

*

This discussion has been archived. No new comments can be posted.

Book Review: A Practical Guide To Linux Commands, Editors, and Shell Programming

Comments Filter:
  • by Anonymous Coward

    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".

  • ... 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':

    mac:~ me$ cal
    March 2013
    Su Mo Tu We Th Fr Sa
    1 2
    3 4 5 6 7 8 9
    10 11 12 13 14 15 16
    17 18 19 20 21 22 23
    24 25 26 27 28 29 30
    31
    mac:~ me$ CAL
    March 2013
    Mo

    • by CoderBob (858156)
      No experience with OS X, but the second format looks like ncal instead of cal. Perhaps you have an alias for ncal that is defined in .bashrc or .profile or whatever the OS X equivalent is? On my Crunchbang box ncal looks similar to what you posted but has Sunday at the top and doesn't jam weeks 1 and two into one line (maybe a victim of copy & paste?)
    • Sounds like your CAL somehow redirects in some cases to ncal - probably a bug in the filesystem.
      • by hawguy (1600213) on Monday March 25, 2013 @04:37PM (#43275537)

        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 Anonymous Coward

          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.

          • by hawguy (1600213)

            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?

          • by Darinbob (1142669) on Monday March 25, 2013 @07:22PM (#43277089)

            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.

    • by Dagger2 (1177377) on Monday March 25, 2013 @03:40PM (#43274963)

      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.

      • by Dagger2 (1177377)

        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.

    • 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.

    • by hawguy (1600213)

      ... 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 /usr/bin/cal /tmp/CAL
      $ /tmp/CAL
      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 /usr/bin/cal
      lrwxrwxrwx 1 root root 4 Jan 19 00:52 /usr/bin/cal -

    • 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.

    • by packrat0x (798359)

      The second is ncal output.

    • by jones_supa (887896) on Monday March 25, 2013 @05:12PM (#43275929)
      The "cal" program checks if it has been called exactly with the lower-case command "cal" and displays the horizontal format. Otherwise it displays the vertical format. The reason why the other commands such as "CAL" work are due to the case-insensitive filesystem in Mac.
  • Thanks for reviewing this book, which appears to have been published in early Fall of last year. Since it's a book on the commands, editors, and shell programming, it'll probably be valid for years to come. (I've had college instructors require students to purchase texts that were "only" four years old, but already severely outdated by that point.)
    • 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.

      • by EvanED (569694)

        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

        • by Anonymous Coward

          PowerShell is actually pretty awesome.

          Yep, pretty awesome [briancarper.net] alright.

          • by Darinbob (1142669)

            Ha, "ripoff of bash". As if sh, csh, or ksh never existed...

            • by EvanED (569694)

              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.

        • Actually, there was a major upgrade in the Windows CMD shell from NT4 to Windows 2000. The CMD shell is surprisingly powerful, but poorly documented. The best documentation is available in the man pages, which can be accessed by the HELP command.
        • Anyone who's used BASH for any amount of scripting knows how useless PowerShell is as soon as they play with it.

      • I did some work on one of Mark's other books, so he still periodically sends me copies of any that contain snippets that I wrote. I've got the second edition lying around somewhere (I think it contains a total of about three pages of text I wrote, no idea if there's anything of mine in the third edition). Most of the stuff is pretty timeless, but as I recall this book also talks about various configuration things. One of the reasons I switched from Linux to FreeBSD is that these have a habit of changing
    • by Anonymous Coward

      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

    • by El Rey (61125)

      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)

    by 101percent (589072) on Monday March 25, 2013 @03:27PM (#43274813)
    This book is great. My school used the previous edition for intro to Linux. It's a great distro-agnostic reference.
  • expect (Score:4, Informative)

    by udachny (2454394) on Monday March 25, 2013 @03:30PM (#43274863) Journal

    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.

  • Just "sold". Was looking for a good book on this.
  • 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.

    • by Mr Foobar (11230)

      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.

    • 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

    • 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.

"In matters of principle, stand like a rock; in matters of taste, swim with the current." -- Thomas Jefferson

Working...