Slashdot Mirror


Linux Commands, Editors, & Shell Programming

norburym writes "Mark G. Sobell is well known for several comprehensive and well-written volumes: A Practical Guide to Solaris; A Practical Guide to Red Hat Linux: Fedora Core and Red Hat Enterprise Linux (2nd ed.); and A Practical Guide to the Unix System (3rd ed.). It seems only natural for the author to follow these exceptional examples with yet another excellent book entitled A Practical Guide to Linux Commands, Editors, and Shell Programming . Read on for Norburyms' review. A Practical Guide to Linux Commands, Editors, and Shell Programming author Mark G. Sobell pages 1008 publisher Prentice Hall PTR rating 9 reviewer Mary Norbury-Glaser ISBN 0131478230 summary Linux Commands, Editors, & Shell Programming

While the author has covered some aspects of this material in A Practical Guide to Red Hat Linux: Fedora Core and Red Hat Enterprise Linux, there is more than enough here (in-depth coverage of the vim and emacs editors; tcsh; sed and gawk; and the command reference section that comprises Part V) to make this a new and exhaustive volume that should take top dog in anyone's Linux library.

Sobell splits the book into six parts with Chapter 1 acting as a preface to the rest of the book. It gives a history and an overview of Linux and discusses distinctive aspects of the operating system that make it different from others. We've all heard and read the arguments before: Linux is superior to Windows, TCO is lower with Linux, Linux is not proprietary, etc. but Sobell avoids this display of arrogance and superiority by treating the origins and features of Linux as an evolution of best practices and common sense. As such, we're not left with a suspicion that the author has blinders on. To the contrary, the reader can proceed with an open mind to learning the intricacies of Linux and the command line.

Part I isn't geared for experienced users of Unix or Linux but it does serve as a good skimming point for those sysadmins who may need to brush up. For the beginner or the novice, however, these four chapters give a compact and succinct introduction to using Linux and set the stage for the sections to follow. Chapter 2 begins with logging in from a Terminal, including emulation, ssh and telnet. The author explains how to tell which shell the user is running; how to work with the shell; and how to use help, man and info. Chapter 3 is a catalog of basic utilities with all the usual suspects: ls, cat, rm, cp, mv, grep, hostname, head, tail, sort, echo, date, etc.; compressing and archiving tools: bzip2, bunzip2, gzip, tar; locating commands: which, whereis, apropos, slocate; commands used to get user and system information: who, finger, w; and commands used for communication: write, mesg. Sobell gives each utility a brief but thorough description of its function, appropriate syntax and practical uses. Chapter 4 is a complete treatment of the Linux hierarchical filesystem: directory and ordinary files; absolute and relative pathnames; how to work with directories; hard and symbolic links; and access permissions. Chapter 5 is where the reader gets a closer look at the shell. Sobell covers command line syntax (command name, arguments and options), processing and executing the command line, standard input and output (including pipes and a really nice explanation of device files), redirecting standard input and output, running a program in the background and aborting it using kill, generating filenames and expanding pathnames using wildcards/special characters, and utilities built into the shell like echo (and how to list bash and tcsh builtins).

Part I is a comfortable read. It moves along quickly and with quite a bit of information but not so much to overwhelm. By the conclusion of Chapter 5, the beginner or novice can feel pretty competent with the CLI.

Part II is dedicated to the vim editor and the emacs editor, both enjoying a chapter to themselves. Sobell happily avoids adding fuel to the already flaming fire of which editor is "the best." Chapter 6, "The vim Editor," and Chapter 7, "The emacs Editor," both use a tutorial approach to demonstrate the use of each text editor. The author includes a brief history of the development of the editor before giving a fairly complete lesson on creating and editing files within that particular editor. Some highlights of Chapter 6 include: vi clones; details of vim commands like join, yank and put; and advanced editing techniques like using markers and creating macros. Chapter 7 features: an explanation of emacs key notation and key sequences; incremental and nonincremental searches; advanced editing techniques like using the buffer to undo changes; using Mark and establishing a Region; yanking killed text; and manipulating windows (splitting and adjusting, for example).

Learning at least one editor to a level of competency is an absolute must. Sobell provides excellent instruction on both vim and emacs and along with the tutorials and the exercises at the conclusion of each chapter the reader will be sufficiently proficient in both to choose a favorite.

Part III, "The Shells," discusses the Bourne Again Shell (bash) and the TC (tcsh) shell with careful detail to each interpreter/language. The author stresses that bash, rather than tcsh, should be the shell of choice for programming and this is reflected in the instruction set forth in each of these two chapters.

Chapter 8 concentrates on bash: shell basics (startup files, redirecting standard error, simple shell scripts, separating and grouping commands, job control, directory stacks); parameters and variables (shell and user-created variables, variable attributes, keyword variables, special characters); processes (structure, identification); history mechanisms (reexecuting and editing commands, referencing events using !, use of the Readline Library); using aliases; shell functions; controlling bash features and options (using command line options and the set and shopt builtins); and a description of how bash processes the command line (command line expansion).

The TC Shell (tcsh) gets equal attention in Chapter 9. The author aims to show how tcsh differs from bash while providing a broad overview of the shell: shell scripts; entering and leaving tcsh; tcsh startup files; features common to bash and tcsh (and how tcsh implements them in a different manner) including command line expansion (tcsh calls it "substitution"), history, aliases, job control, filename and command substitution, and directory stack manipulation; redirecting standard error using >&; command line (word completion, command line editing, spell correction); variables (substitution, string variables, arrays, numeric variables, using braces, shell variables); control structures (if and goto, interrupt handling using onintr, if...then...else, foreach, while, break and continue, switch); and tcsh builtins.

Part IV, "Programming Tools," is the logical progression from the previous discussions of editors and shell basics. Sobell splits this part over four topics: programming tools, programming bash, gawk and sed.

The focus of Chapter 10 is programming tools. In particular, attention is given to writing and compiling C programs. Sobell shows how to check for your GNU gcc compiler and then gives a C programming example with a simple C program that converts tabs to spaces while maintaining columns. He takes this a step further by compiling his example C program to create an executable file. He also addresses shared libraries, fixing broken binaries, using GNU make to resolve dependencies, debugging techniques, threads, and system calls for filesystem operations and for processes control. I especially like the inclusion of the make utility. Sobell provides a nice graph that shows dependency relationships and uses an example makefile to illustrate dependency lines and construction commands. The rest of the chapter deals with source code management and using the CVS (concurrent versions system) utility and TkCVS (a Tcl/Tk-based GUI to CVS).

The next chapter is a return to bash with more detail to shell programming. The author uses this section to cover control flow contructs (if...then, if...then...else, etc.); file descriptors; more detail on parameters and variables (array variables, locality of variables, special parameters like $$ and $?, positional parameters like $#, $0 and $1-$n); expanding null and unset variables; bash builtin commands (type, read, exec, kill, etc.); and expressions (including a table of bash operators). The chapter concludes with the creation of two example shell programs: a recursive shell script that illustrates recursive operations and a "quiz" shell script which presents questions with multiple choice answers. The author walks through both of these step-by-step and points out potential pitfalls as he creates and executes a working design. Sobell should be congratulated for putting together a well-balanced and complete chapter. The exercises are thoughtfully constructed.

The Gnu awk (gawk) utility and the sed (stream editor) utility complete the final two chapters of the book. Both chapters include syntax, arguments, options and a fair number of examples.

Part V is the command reference section and this constitutes a volume in itself. This is, essentially, a printed version of man pages of utilities and shell builtins. Sobell gives us a bonus above Linux man pages, though: he includes extremely useful and pithy examples with each entry along with interesting discussion and notes sections. I would love to see the "Command Reference" as an electronic, searchable version! Perhaps as a CD included with the book in future, instead of in print.

The Appendixes make up Part VI. Regular expressions used by gawk, sed, vim, emacs, etc. are described in Appendix A. Help options, including Web sites for documentation on Linux systems (GNOME, GNU, KDE, etc.), Linux newsgroups and mailing lists, software packages (CVS, Freshmeat, Sourceforge, Tucows-Linux, etc.), Office suites (AbiWord, KOffice, OpenOffice, etc.), and how to specify a Terminal make up Appendix B. The last appendix shouldn't be ignored or overlooked: Keeping the System Up-To-Date. This section describes yum, Apt and BitTorrent. Kudos to the author for reminding readers to maintain their systems and providing good instructions on how to do so.

A Glossary of terms and the Index conclude the book.

The layout of the book is well designed: the typography is comfortable to read and, although physically hefty, the dimensions of the book give the reader a nicely balanced paperback. Nothing fancy but excellent quality and eminently readable with delineated examples and good font choices.

Every chapter begins with a brief introduction and ends with a chapter summary, exercises, and advanced exercises where appropriate. The exercises are a highlight of the book: Sobell has obviously given these a lot of thought and they are exemplary of the chapter topics that they reference. Answers to even numbered problems can be found at the author's Web site.

Overall, it's hard to find anything to complain about here that wouldn't sound inconsequential and trifling. No mistake, this is a big book: Part V alone (command reference) is a volume in itself. But I can't see anything extraneous or non-essential here. The author combines all the important features and tools together with the appropriate and necessary references.

Sobell has compiled an extensive volume that both newcomers to Linux and experienced users will find extremely useful. Once in hand, A Practical Guide to Linux Commands, Editors, and Shell Programming becomes not only a complete tutorial but also an invaluable resource that will be referenced time and again. This is as close to a textbook as you can get without being tormented by dry sterile language; Mark G. Sobell clearly has a command of his subject and he exudes a passion that infuses his writing and clearly elevates this book above any mere manual. This will become a standard and as such, a "must have" for anyone serious about learning command line scripting.

You can purchase A Practical Guide to Linux Commands, Editors, and Shell Programming from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

118 comments

  1. vim vs emacs? by MyIS · · Score: 5, Funny
    Sobell happily avoids adding fuel to the already flaming fire of which editor is "the best."

    /me secretly winks at author for placing the vim chapter first

    --
    http://zero-to-enterprise.blogspot.com/
    1. Re:vim vs emacs? by Anonymous Coward · · Score: 2, Funny

      /me secretly winks at author for placing the vim chapter first

      /me agrees with your positive assessment. The author has wisely saved the best for last.

    2. Re:vim vs emacs? by VolciMaster · · Score: 4, Insightful
      apparently he doesn't believe in listing alphabetically, then :)

      Yes, I'm an emacs user. I can also use pico when nothing else is available.

      As religious as the emacs v. vim wars get, the real point is whether or not you can get the task done with a tool. I've met people who were really, really good at using pico, equal to my level of comfortability with emacs. I've met vim users who are really efficient. And I know lots of people, like myself, who are quite productive in emacs.

      Whatever tool you use, if you can be productive, ie get the job done in the specified time-frame, I honestly don't care what editor you use. That's the cool thing about having lots of editors to choose from, you can pick the one that fits how you think.

      I think in emacs. One of my best friends thinks in vim. We're equally productive in our environments, which is what really counts.

    3. Re:vim vs emacs? by Omega1045 · · Score: 1
      Right.

      What gets me is when one is not installed on a system. Why not install all of them? You can probably install the 3 you mention and have all of the bases covered with minimal disk space.

      I actually ran into a sysadmin that would only allow vi to be on his systems. He would actually go in and remove the others. This lead me to learn vi since I had to use "his" systems. One will always find vi or vim, and most of the time one will find emacs installed. So I use vi. I have had a lot less luck with pico, my old fav from college. I have never understood the war over these. I think me geek cred is pretty good, but really, what is the deal?!

      --

      Great ideas often receive violent opposition from mediocre minds. - Albert Einstein

    4. Re:vim vs emacs? by Breakfast+Pants · · Score: 1

      Yes, his railing on emacs certainly was better than his praise of the superiority vim.

      --

      --

      WHO ATE MY BREAKFAST PANTS?
    5. Re:vim vs emacs? by VolciMaster · · Score: 1
      I have never understood the war over these

      From what I understand, it comes down to differing ways of approaching the problem at hand. vi (and vim) was written in a moded fashion. All navigation, writing, and editing is just a key away. emacs is modeless, so accessing editing functionality is done through meta (esc) combos and ctrl sequences. I find it very natural to use the ctrl and meta sequences, since I came from the two-fisted world of Macs first, where everything is a Cmd or Option combination. I learned DOS well after I started using the Mac, and learned Unix/Linux later still.

      I jokingly berate people for using anything other than the One True Editor(TM), but as long as you can get your work done, it doesn't really matter to me which you run.

      And you're right, installing the Big Two along with a couple other of the smaller editors doesn't eat much disk space. And since it will invite more people to be happy when they're using your system, it's the better idea. We live in the era of dozens of gigabytes (on up) in hard drive space. There's no reason you can't have 5 editors installed. Most admins have more than one browser installed (in an X environment), so why not more than one editor? Most distribution include vim and emacs in the default install anyway.

      People that are that die-hard about their systems are probably not good people to have as sysadmins. I use MacOS, Windows, and Linux. I find they each have reasons to exist, and I try to use them each to their individual strengths. The same should be true of editors, or any other tool where there is more than one option. I really dislike Internet Explorer, but I still use it (if for no other reason than to verify site designs). I also use Opera, Firefox, Lynx, and links.

      Computers are supposed to make our lives easier by giving us tools to work with. Devolving into the religious wars between two equally good (though quite different) tools doesn't help.

    6. Re:vim vs emacs? by kuzb · · Score: 1

      /me secretly winks at author for placing the vim chapter first

      You're right, it's better to get the bad news out of the way first.

      --
      BeauHD. Worst editor since kdawson.
  2. A practical approach to learning by SlashdotMirrorer · · Score: 5, Insightful

    Any bearded terminal hacker will tell you, when asked about the book they learned from, that while they went from one book to another in their early days, the most productive thing they ever did was learn how to read the documentation already available to them. This includes man pages, changelogs, posts to dailydave, and source code. A lot of people completely neglect these wonderful sources, and even go so far as to reinvent the wheel writing their own guides (see early Mandrake and Redhat releases).

    Someone should write documentation on how to read documentation (especially source!)!

    1. Re:A practical approach to learning by MyIS · · Score: 5, Insightful

      I know a lot of people that would prefer a physical book over online docs anytime. The key difference between the manpages and a guide like this is how the latter places everything into some sort of context. That is, a novice would get a much more useful "bird's eye" view of the available toolset by reading a guide on Unix user management as opposed to directly researching manpages for adduser, passwd, finger, etc. Mind you, I love reading manpages, but I think I could have saved a lot of my own learning time back in the day, if there was a nice tutorial nearby and I wasn't so stubborn to do things the hard way.

      Of course, manpages are impossible to avoid in day-to-day work, but a good guide is invaluable as a kick-start.

      --
      http://zero-to-enterprise.blogspot.com/
    2. Re:A practical approach to learning by Anonymous Coward · · Score: 1, Funny

      I personally have found that documentation books can be very useful. I have my monitor stacked on top of several right now to achieve the correct height so that it is more comfortable to use my computer. I have another pile on the floor acting as an ottoman.

    3. Re:A practical approach to learning by CaptainFork · · Score: 0

      Man pages are fantastic. I love man pages. But reading source is over-rated. The 0.00000000000000000000001% of sources that are well-commented are OK, but mostly you want to be told what the software is supposed to do.

    4. Re:A practical approach to learning by clintp · · Score: 5, Insightful
      Any bearded terminal hacker will tell you
      Except that many modern systems that would like to call themselves Unix (or Unix-like) don't ship man pages. They ship info pages.

      Garbage. Blasphemy of the highest order.

      Shaved the beard in '98, but have been hacking Unix since '85.
      --
      Get off my lawn.
    5. Re:A practical approach to learning by Fecal+Pump · · Score: 1

      Yes, but by running a Google search on, say, awk, you run a substantial risk of inadvertently launching an ICBM and initiating a global thermonuclear war.

    6. Re:A practical approach to learning by myvirtualid · · Score: 5, Insightful

      The parent makes two points: 1) that us terminal hackers went from book to book while they learned, and 2) that the documentation already available was where they learned the most.

      Re #2: No argument there, the information that comes with a well-documented UNIX is the best way to achieve wizard or guru knowledge levels. Not quite so well suited for getting as far novice, though: A lot of the man pages - at least back in the day - were written by experts who assumed the reader was close to expert, or at least was a C coding system hacker. Like it or not, not all of us were. C coder? Yes. Sysadmin? Eventually? Kernel hacker? Nope. Library hacker? Only at gunpoint. Shell hacker? Oh, yes, please anytime.

      How does one climb from naive to novice to comfortable to proto-admin, how does one get to the point that some of the denser available material starts to be beneficial, rather than a poor imitation of nethack? You are in a twisty maze of man pages, without doors or windows, and your dog has died....

      Context, and clear and lucid introductory material. That's the starting point. That brings us to...

      ...point #1: Bounce from book to book? Not so, this terminal hacker. When a job change took me from system 370, where I could hack REXX and JCL with the best of them, to UNIX, where I do better than hold my own in sh and sed, with a little awk/nawk/gawk thrown in, I sat down with one book. Just one. Sobell's Practical Guide to the Unix System. That's all it took: Three days of working through SunOS (3.?) and HP-UX (6.5, yikes) with that on my lap, and I had found my home! UNIX, beloved UNIX.

      After Sobell, I was ready to tackle the man pages and get some value.

      So am I going to buy this new tome? Well, let's think about that description: tome. Why is the Linux Sobell so much fatter than the UNIX Sobell was?

      Beware, flamebait: Possibly because some much of the information available with most distributions is so poor! Man pages that refer to info, and info pages that repeat the man pages word for word, save for the reference to info! Laughable, absolutely laughable.

      And, yes, as others have pointed out, there is much information available on the web. Where to start? And how to tell wheat from chaff? Context....

      Which brings us back to the Sobell Linux tome: Yes, I will more than likely by it, and I'll bet I'll recommend that others do, because my guess is that it will provide the one thing that all us Linux-proto-admins and Linux-proto-hackers need to get started and to start making sense of what's out there: Context.

      By the looks of the review, Sobell's provided plenty.

      Mr. S, hats off for doing it again, and thanks.

      --
      I'm here EdgeKeep Inc.
    7. Re:A practical approach to learning by tekisama · · Score: 0

      Quite right. And Sobell makes that point exactly, over and over again. I use this book to teach an intro to Linux course. He touts the use of man pages and using the internet to look up answers. But that doesn't mean having a handy reference guide by your side as one learning is a cardinal sin ... I love his command reference in the back of every book because it contains basically the man page, plus several *good* examples of using the syntax.

    8. Re:A practical approach to learning by John+Whitley · · Score: 3, Insightful

      In all fairness, this isn't the *nix distributions that are at fault: it's the upstream software developers. Aside from a few valiant distro package maintainers, all docs seem to come from upstream these days. I totally agree that info pages used to suck rocks, mostly because they seemed to be an excuse for really sparse documentation encased in really bad hypertext. Fortunately, the quality of the documentation (and the hypertext organization) has improved considerably over the years...

    9. Re:A practical approach to learning by Anonymous+Cow+herd · · Score: 1

      Too bad I blew all my mod points this morning, otherwise I'd have modded this insightful as well. Honestly I'd rather install windows than use info pages.

      --
      Ita erat quando hic adveni.
    10. Re:A practical approach to learning by mrogers · · Score: 4, Insightful

      Most man pages are references, not tutorials - reading the bash manual page is a horrible way to learn shell scripting.

    11. Re:A practical approach to learning by Cheapy · · Score: 3, Insightful

      What about us people who don't know what commands do what? Man pages are fairly useless if you don't know which command to ask for.

      --
      Would you kindly mod me +1 insightful?
    12. Re:A practical approach to learning by Coryoth · · Score: 4, Informative

      Any bearded terminal hacker will tell you, when asked about the book they learned from, that while they went from one book to another in their early days, the most productive thing they ever did was learn how to read the documentation already available to them.

      While the available documentation (man pages usually) are nice, there are a few books out there that quitte simply are great references and provide better material than the standard documentation. My personal favourite is UNIX Power Tools. It is mostly just a vast, vast collection of tips, tricks and cunning insights into the finer points of UNIX, its shells, and the various command line tools you can expect to find from some exeptionally experienced long time UNIX hackers. It's not a book you sit and read cover to cover, it's the sort of book where you go "I wonder how I could do [obscure thing]?" look it up in the index (another great feature is that the book has one of the most comprehensive and impressive indexes - finding out how to do what you want to do is easy), flip to the relevant section and start reading. Each section is heavily (and well!) cross referenced so in the middle of reading how to do [obscure thing] you read a comment about [other thing you hadn't realised you could do] and have to go and read that section too. An hour or so later you realise that you really need to get back to work and do [obscure thing], but you now also know many cunning ways to exploit UNIX that you would never have thought of yourself, and certainly wouldn't have realised you could do just from reading man pages.

      Jedidiah.

    13. Re:A practical approach to learning by Anonymous Coward · · Score: 0

      Or better yet, figure out that I probably need to use a certain command or script, for which the complete documentation is: "This is a linux port gfoo of the unix foo."

    14. Re:A practical approach to learning by Coryoth · · Score: 4, Interesting

      What about us people who don't know what commands do what? Man pages are fairly useless if you don't know which command to ask for.

      Heh. Never underestimate the value of spending a day working through man pages for every program in /usr/bin, it can be remarkably educational. I admit that's trickier on a lot of modern Linux systems that have so many programs in there, but you can skip over a lot of them (all the obvious KDE and GNOME apps) and only worry about the weird obscure looking ones you don't recognise. A lot of the time you'll do man [obscure command] read the summary at the top and go "Huh, didn't realise there was something to do that" and not worry about it. The point is that one day you'll be sitting there trying to figure out how to do something and remember "I read a man page for something that could do that..." a quick skim through ls /usr/bin and (usually after at most 2 or 3 missed guesses) you can pull up the manpage for what you want. Sometimes knowing that there is something that can do [obscure task] is the most important part. Other than that, reading the man page through for some of the more common commands that have a vast array of switches (ls, grep, cut, sort, etc.) can make you realise that some of those can do things you really wouldn't have expected them to be able to , and suggest cunning new ways to use them is tasks where you might not thought they would apply.

      Just knowing what's available and all the various things that can be done with the tools is a very valuable lesson, and worth a little time investment. It takes less time than you might think to skim through and at least become acquainted with what all the various obscure programs in /usr/bin actually do.

      Jedidiah.

    15. Re:A practical approach to learning by Anonymous Coward · · Score: 2, Insightful

      Oh christ, someone needs to drag info out back and shoot it. I tend to forego documentation in favour of trial and error rather than struggle to remember how to navigate that awful heap of junk.

    16. Re:A practical approach to learning by disappear · · Score: 1

      My book teaches how to read documentation. It's the subject of the first chapter, actually. (Slashdot reviewed my book, long ago, FWIW.)

      Since my book is not aimed directly at programmers, I didn't cover reading source code. I did cover basic instructions for debugging documentation when it's wrong, though.

    17. Re:A practical approach to learning by molo · · Score: 1

      FYI, Debian policy is to have a clear and useful man page for each executable it ships. This means that there are debian-authored man pages for packages that only ship info pages upstream, or even no man page from upstream.

      -molo

      --
      Using your sig line to advertise for friends is lame.
    18. Re:A practical approach to learning by LodCrappo · · Score: 2, Interesting

      A very good point. Also, by reading through the common util's man pages, in addition to knowing there's a tool to do a certain task (which you might forget, or not even understand at the time), you start to get a "big picture" understanding of unix. You learn how to look at a new task and break it down in to categories: "this part is very general and there must be a tool to do it", "this part is specific to my task but could be done using general tools", and "ok, i'm going to have to write some code here". Being able to properly break down a task and use the available tools to your advantage is truely the difference between a hacker and a hack, in my humble opinion.

      --
      -Lod
    19. Re:A practical approach to learning by Anonymous Coward · · Score: 0

      man -k

    20. Re:A practical approach to learning by ericbg05 · · Score: 2, Funny
      Someone should write documentation on how to read documentation

      $ man man
    21. Re:A practical approach to learning by Anonymous Coward · · Score: 0

      _Code Reading: The Open Source Perspective_ by Diomidis Spinellis covers how to read source code.

    22. Re:A practical approach to learning by IntlHarvester · · Score: 2, Insightful

      I don't understand this argument at all. You pay RedHat and SUSE good money for packaging. If something about the packaging sucks (docs are an inconsistent mix of info, man, html, and text), you expect them to fix it and not shrug their shoulders and point upstream.

      --
      Business. Numbers. Money. People. Computer World.
    23. Re:A practical approach to learning by belmolis · · Score: 1

      Try the -k option to man followed by something you're interested in. It will give you a list of relevant man pages. For example, if I type:

      man -k compiler
      I get a list that includes bcc, gcc, javac, luac, ocamlc and other compilers. You will sometimes get a lot of stuff that you aren't really interested in, and it may miss things that you would like to check out, but its still very handy. It will often remind of the name of a program you can't recall or suggest useful things to read about.
    24. Re:A practical approach to learning by Anonymous Coward · · Score: 1, Interesting

      I actually purchased this book a couple months ago shortly after I finally made the fateful jump to Linux (Ubuntu) from Windows.

      The problem with the man pages is that I had seriously no idea how powerful the terminal could be. I had never seen file redirection, pipes and had only used a very small subset of common utilities previously. Obviously, I doubt if I ever would have found information on these things that I had no idea existed in the first place.

      I learned a helluva lot from this book (and quickly) but one of the great things about this book is that it encourages the reader to go further than the book itself. The end of chapter exercises ("Advanced Exercises") often incorporate solutions that the chapter didn't explicitly cover...but by using google, man pages and "--help", nothing was impossible. Also, the broad range of Linux issues covered (scripting, vim, cvs, sed, etc...) was impressive to me and helpful in understanding a lot of the things that seemed rather mysterious about the Linux way-of-doing-things at the time.

      For the first time I feel like a real "power-user" and I have to thank this book for a lot of that. I'm writing and modifying bash functions and shell scripts virtually every day and having a lot of fun with it. The book is not as useful or all that relevant to self-proclaimed "Terminal hackers" as much as it is to newbies like me.

    25. Re:A practical approach to learning by mrsbrisby · · Score: 1

      What about us people who don't know what commands do what? Man pages are fairly useless if you don't know which command to ask for.

      apropos?

      On my system, I needed to find all the tools that involved mpeg operations because I simply didn't know, so I used:

      $ apropos mpeg

      and was greeted with:

      .br mp2enc [mp2enc] (1) - Simple MPEG-1 layer-II audio encoder
      .br mplex [mplex] (1) - MPEG 1/2 program/system stream multiplexer
      SDL::MPEG (3pm) - a SDL perl extension
      YUV4MPEG2 [yuv4mpeg] (5) - video stream format used by pipe-based
      ...

    26. Re:A practical approach to learning by joel48 · · Score: 1

      Have you actually read most of the debian-generated man pages? They most often don't say anything more than "This man page written for Debian in order to comply with policy". If the program needs a manpage then write a good one, otherwise override the lintian check.

    27. Re:A practical approach to learning by Bob+Uhl · · Score: 1
      Re #2: No argument there, the information that comes with a well-documented UNIX is the best way to achieve wizard or guru knowledge levels. Not quite so well suited for getting as far novice, though: A lot of the man pages - at least back in the day - were written by experts who assumed the reader was close to expert, or at least was a C coding system hacker. Like it or not, not all of us were. C coder? Yes. Sysadmin? Eventually? Kernel hacker? Nope. Library hacker? Only at gunpoint. Shell hacker? Oh, yes, please anytime.

      I disagree, actually. They weren't written for experts, but they were written for folks willing to spend a fair amount of time learning. I was 13 when I started using Unix in the lab at ODU, and I didn't have much of a problem: I just read the man pages, and read 'em again (that was back when more couldn't back up a page, and so if I wanted to read the previous page I had to quit and start all over again), and read 'em yet again until I began to figure 'em out.

      I'm a Unix admin by trade now, so something must've stuck...

    28. Re:A practical approach to learning by Anonymous Coward · · Score: 0

      You're right; man pages don't teach shell programming well (except the bash page, to a small degree). But one of the three topics of the book is "Linux commands", as reflected in the title. And for learning and remembering how to use Linux commands, I agree with the suggestion:

      cd /usr/bin; for a in *; do man $a; done

      It's like flashcards for Linux commands.

    29. Re:A practical approach to learning by RAMMS+EIN · · Score: 1

      ``(another great feature is that the book has one of the most comprehensive and impressive indexes - finding out how to do what you want to do is easy)''

      This is what sets apart good books from great books: having a good index. Not just for informative books, but for any books, even fiction. It's also one place where electronically available information will always have the edge.

      --
      Please correct me if I got my facts wrong.
    30. Re:A practical approach to learning by cortana · · Score: 1

      Randall Waterhouse? Is that you?

  3. Why buy the book? by MLopat · · Score: 2, Insightful

    Why would anyone spend the money on this book?

    The information presented in it is freely available all over the web, often with more insightful examples, tutorials, etc. I just don't see the justification in spending x dollars on a book when a simple google search will yield a better result for free.

    1. Re:Why buy the book? by hildaur · · Score: 5, Insightful

      Google searches (and online documentation found by other means) are great for finding details about stuff you already know exists. They stink at helping you discover really useful tools it never occurred to you might exist.

    2. Re:Why buy the book? by MLopat · · Score: 1

      While I think that's true for some topics, in the technology field there seems to be alot of information available. For example, look at this google search for Linux Shell Tutorial. Looks like alot of info to me.

    3. Re:Why buy the book? by the_consumer · · Score: 0

      I think it's the combination of tightrope-taut plot with genuinely affecting character development that makes this book stand out from your run-of-the-mill online documentation. I must have fallen asleep with the light on for a week straight, and was especially moved by the author's probing insights in the maturation of ed into sed.

      --
      "If you're thinking what I'm thinking, you're right." -
    4. Re:Why buy the book? by DonVino · · Score: 3, Insightful

      Because sometimes I like it to read about something ordered and structured. And maybe there are things in this book, that you don't google that fast or maybe you find a tool, that you wouldn't have found with google - or maybe just not that fast.

      - often with more insightful examples, tutorials, etc -
      I you need more insightful examples, you can still google for it, but for a first impression this should be enough.

    5. Re:Why buy the book? by Shadow+Wrought · · Score: 4, Insightful

      I'm considering it because I'm new to Linux and my home computer is not hooked up to the internet. Using Google means either running back and forth to the other computer or finding answers during lunch. Sitting down with an actual book is still a handy thing, and will continue to be so, regardless of how helpful google can be.

      --
      If brevity is the soul of wit, then how does one explain Twitter?
    6. Re:Why buy the book? by $RANDOMLUSER · · Score: 3, Insightful

      I do have an answer for this. I have two 3-inch binders full of man pages for the shell, awk, lvm, ioscan, etc, etc. Every single hardware-related thing, no matter how arcane, and every commonly used thing I can't remember all the arguments to. Normally they sit at my desk, but they always go with me for my bi-annual trip to the off-site disaster recovery center. One of the lessons I learned a long time ago is you have to have a machine running to use the on-line help. When the box is casters-up, you're on your own.

      --
      No folly is more costly than the folly of intolerant idealism. - Winston Churchill
    7. Re:Why buy the book? by Anonymous Coward · · Score: 0

      Because I don't like to use my computer while I'm taking a dump. A book on the other hand...

    8. Re:Why buy the book? by value_added · · Score: 1

      The information presented in it is freely available all over the web ...

      And having things all over instead of in one place is a Good Thing?

      Dunno about you, but it seems to me that reading a few hundred manpages or clicking through a few hundred links is neither practical nor comprehensive, which I believe is the purpose of this book.

    9. Re:Why buy the book? by suitepotato · · Score: 1

      Sometimes it is easier to have hardcopy at your side instead of flipping between windows to see what the Google results are and often your printer doesn't work for whatever reason or is nonexistant. A good book can also be curled up with at night before bed. Try doing that with a tower PC.

      --
      If my grammar and spelling are off, I am [distracted/tired/careless] (take your pick)
    10. Re:Why buy the book? by MLopat · · Score: 1

      Well I agree that keeping notes is handy, but surely having them indexed on a computer is just as simple, more portable, and easier to pass around. And yes you have to have a machine running to use the online help, but how many people doing shell scripting don't have a second computer at their disposal should something happen to the first one?

    11. Re:Why buy the book? by sumdumass · · Score: 2, Insightful

      I would buy it. If nothing else then a reference when the internet os dopwn and i cannot quite remeber/figure somethign out. Saveing web docs and then viewing or p[rinting them to be viewed elsewere sometimes doesn't cut it.

      I remeber a time not so long ago when i was trying to script a simple "run after this happens " dialog to search the logfile and determin if it was a simple restart a service or if something needing more attention and then email different people based on the responce. I was on a production server without internet acess and it turned i just spelled a couple commands wrong and threw a couple switches in an incorect order. A reference book like this would have made it real easy to figure out. This is especialy true when after thinking about it, i remember having to sit and and think about the commands i had problems with for a while before i eventualy used them.

      Learning from the internet is fine. Having a book in type that doesn't hurt your eyes for reference and refresher reading is worth a couple $. I would say that it might be even worth a couple hundred $, (if it is spread out over several books.).

    12. Re:Why buy the book? by jcarter · · Score: 1
      Yeah, but how much of it is any good? There's no way to know which ones are easy to follow, provide good examples, are no longer live etc.

      With a book on paper, you tend to get a consistent style. Most of the decision process with books is finding an author that writes in a manner that is clear and helpful to you.

      With books, the tendency to reliability is greater (though arguably still none _too_ great), than that of a collection of search results.

      Also, books are just easier. You can take a book more places than even a small laptop. You don't have to concern yourself much with connectivity,power,breakage,dirt,spills, etc.

    13. Re:Why buy the book? by Anonymous Coward · · Score: 0

      Don't you also need to have a machine running to use awk, lvm, ioscan, etc, etc

    14. Re:Why buy the book? by robertjw · · Score: 1

      The information presented in it is freely available all over the web, often with more insightful examples, tutorials, etc. I just don't see the justification in spending x dollars on a book when a simple google search will yield a better result for free.

      How am I supposed to curl up next to the fire with a google search, or go camping with a google search. I need the book so I can read it wherever I want, whenever I want.

    15. Re:Why buy the book? by jaydonnell · · Score: 1

      When your learning it is nice to have a thought out progression of subjects. Searching around and finding good pieces of information here and there isn't a good learning environment for a beginner. I read one of his other books when I was just learning linux and it made life much easier for me.

    16. Re:Why buy the book? by robertjw · · Score: 1

      Well yeah, to USE them... but if a person would just want to read about them a book is fine.

    17. Re:Why buy the book? by $RANDOMLUSER · · Score: 1

      If I'm creating logical volumes and such, I don't have the man pages installed yet, do I?

      --
      No folly is more costly than the folly of intolerant idealism. - Winston Churchill
    18. Re:Why buy the book? by wuice · · Score: 2, Insightful

      Please get off your high horse. A book puts stuff together in a way that someone with no prior experience to a subject (who doesn't really know what to "google" for, and would like a comprehensive guide to a subject instead of trolling for a dozen links.

      What I hate about comments like these is that they're almost always bragging in a thinly-veiled way... "*I* figured it out on my own, why can't time-strapped IT professionals do the same?" The answer is the time it would take to compile such a comprehensive resource is worth MORE to some people than the price of the book. Books also tend to have a more comprehensive goal in mind (ie, you build on what you learned in the last chapter), whereas most websites and HOWTOs are atrocious resources except for the individual task the websites is dedicated to. Also, books tend to be written by professionals, editied by professional editors, as opposed to random people spewing on the net. My experience is that googled examples tend to be much less insightful, more likely to be contradictory, tutorials thrown together, etc.. In the OSS world especially, so populated by hackers, documentation that makes sense to non-hackers is very low on the list of priorities.

      If you learned this stuff with nothing but google and loads of spare time, congratulations, give yourself a gold star.

    19. Re:Why buy the book? by MLopat · · Score: 1

      Nope, not bragging at all. In fact, nothing to brag about. I havn't used a unix shell since I was taking computer science at uni. So I'm the furthest thing from an expert on this topic.

    20. Re:Why buy the book? by Iago515 · · Score: 1
      I'm fairly new to Linux, too, and I don't know what I would have done without the internet at my disposal. I don't think that books are really the be-all to end-all to Linux installation. SuSE, Fedora and Ubuntu are all simple for different reasons (right now my distribution of choice is SuSE because I'm trying to get iFolder working) and for most stuff you won't need a manual, but if you do run into a problem, manuals will give you the general overview of how to do things, which is invaluable, especially with things you can do from the command line, but they won't give you much insight for your specific problem (whatever it may be).

      But the problem with online help is the people who write them often forget to add a command that might be obvious to a more experienced user or make a typo, both of which can cause hours of frusteration (trust me: either they are I missed a "make install-hotplug" recently and it cost me a day.

      Of course the above advice could be wrong/useless because you could be starting from a point much more advanced than me and/or I could just be too stupid for Linux.

      But the modern distros are really worth the effort if 1. You enjoy a bit of a challenge, 2. You want to learn about the amazing things the OSS community is putting out and 3. You want to really learn about the power of the computer without spending 1000's on software.

      Oh, and remember to make notes when you learn a new command or solve a problem, they will come in invaluable when you decide to check out another distrubtion and run into the same problems again.

      --
      Take note, take note, O world,

      To be direct and honest is not safe.

    21. Re:Why buy the book? by dzafez · · Score: 1

      reference to reallifecoomics.com :

      Books? I heard of these, aren't they portable Websites??

    22. Re:Why buy the book? by Daniel+Dvorkin · · Score: 1

      Why would anyone spend the money on this book?

      The information presented in it is freely available all over the web, often with more insightful examples, tutorials, etc. I just don't see the justification in spending x dollars on a book when a simple google search will yield a better result for free.


      There are at least three answers:

      1) The information you get from your "simple google search" may or may not be better than what you get from the book.

      2) A book provides all the information in one place, with a (hopefully) consistent style, and if well-indexed, will point you to the right information even faster than the Godlike powers of mighty Google.

      3) There are a whole hell of a lot of programmers who, believe it or not, find printed documentation easier to use, in many circumstances, than online. Look, I love online documentation, both local (man pages etc.) and on the web. But it's not the be-all and end-all. There are times when reading about something, on paper, or having the book right there to refer to when working, simply works better than trying to extract the same information from the screen.

      --
      The correlation between ignorance of statistics and using "correlation is not causation" as an argument is close to 1.
    23. Re:Why buy the book? by Anonymous Coward · · Score: 0

      Get a laptop.

    24. Re:Why buy the book? by MrCopilot · · Score: 1
      One of the lessons I learned a long time ago is you have to have a machine running to use the on-line help.

      First, Assuming you arrive onsite to a machine "not running"( What no power? No Console? No X?) What situation are you going to use these binders for without the "machine running" Second...You go offsite with no system of your own?

      How much would you pay for a minitaure electronic USB-Rechargable battery operated Version of your binders? Ebook? Maybe a complete linux distro? man info html txt removable storage? Sounding better

      Don't answer yet. No actually, answer, how much is reasonable? What are the minimum requirements. Not a laptop, Not a PDA, Not another mp3player. Just checkin.

      --
      OSGGFG - Open Source Gamers Guide to Free Games
  4. No Z Shell? by Anonymous Coward · · Score: 0

    I thought zsh has now established itself as a popular alternative to the two shells in the book. Was it even mentioned in the book?

    1. Re:No Z Shell? by tekisama · · Score: 0

      Mentioned in passing, much like csh and ksh.

  5. Re:Trolling, sorry by Anonymous Coward · · Score: 0

    I have a water bottle on my desk. A telephone, that I never use, and a Fed Ex box.
    So yea, I'm struggling here.


    Thanks for the info Brian, I'll be sure to bring this up during your anual review.

    -Charles

  6. Get into the habit of reading the source docs by max+born · · Score: 2

    This sounds like a great book. I don't won't come across as being too negative but having been a Unix sys admin for nearly 10 years and having run Linux on a loptop as my sole OS for the past five years I think it's important for new folks to not rely too heavily on learning from books.

    The great thing about Linux is that all the definitive documentation (including the source code) comes with the OS. It's good practice to get into the habit of using these docs.

    Then again I appreciate that everyone has a different approach to learning.

    1. Re:Get into the habit of reading the source docs by Anonymous Coward · · Score: 0

      i always wondered how well linux runs on a laptop

    2. Re:Get into the habit of reading the source docs by sinewalker · · Score: 1
      The great thing about Linux is that all the definitive documentation (including the source code) comes with the OS.
      You know, I'm finding that for a lot of the "beginner" linux distro's, this is not true. Yes, the source is available but it doesn't come with the OS.

      Granted, not everyone wants to fill their harddrives with source tarballs or SRPMs on the off chance they might want to read them, but only a few distro's I know come with source, and those are not necessarily for noob's. the main example that comes to mind is Gentoo (since it's a "ports"-like distribution). This is not to wax lyrical on the benefits of Gentoo for learning Linux (Gentoo has many weaknesses in that regard too, among its inappropriateness as a general OS for noob's), just that it's the only one I've found where the source comes with the OS.

      Other distro's with source "available" are Debian and Fedora (on extra CDs you have to download, and Fedora locks the source into SRPMs which is another learning hurdle to leap over, especially bad if all you want to do is read the source comments, or documentation not included in the binary RPM). It makes me feel like a 2nd-class citizen, that the source is somehow "open" but you have to know the secret handshake to get at it.

      All of this, just to say: while reading source docs is a laudable habbit and I share your wish to encourage it, I can also see how it is difficult for most Linux noob's to form this habbit so long as the source doesn't actually come with the OS, which for a great many distro's it does not. The extra steps to download (and in many cases extract from SRPMs) the source are probably enough of a deterrent to forming this habbit.

      unfortunately, hacker habbits require hacker motivation :-(

      --
      “Our opponent is an alien starship packed with nuclear bombs. We have a protractor.” — Neal Stepnenso
  7. vi by faqmaster · · Score: 0, Flamebait

    vi is better

    --
    Are you...Are you some kind of genius?
    No, ma'am, I'm just a regular Slashdot reader.
  8. vim and emacs? by stanthegoomba · · Score: 3, Funny

    'cat' and 'echo' ought to be enough for anybody.
    ^D

    1. Re:vim and emacs? by Mercano · · Score: 1

      I'm in the nano\pico camp myself, what with its advanced WYTIWYG (What you type is what you get) technology. Of course, I do have an odd notion that if you open a text editor and start banging keys, letters should start appearing. Silly me. I blame it on my Machintosh upbringing.

      --
      #include <signature.h>
    2. Re:vim and emacs? by CDarklock · · Score: 1
      Who needs echo?
      cat > main.c
      ;)
      --
      Microsoft cheerleader, blue flag waving, you got a problem with that?
    3. Re:vim and emacs? by daeley · · Score: 1

      Machintosh

      Banged a little too hard there, chief. ;)

      --
      I watched C-beams glitter in the dark near the Tannhauser gate.
  9. Seems interesting... by Chickenofbristol55 · · Score: 1

    ... I wish I had the time and energy to learn all this, but I'd rather ask my linux geek (Obviously I am a geek too) friends to help me. How do I install the Mplayer plugin to firefox? (doing that crap always irritated me), istead of watching some good pr0n I had to unpack binaries, my balls and brain loathe you Linux (Not trying to be a troll, just kiddin')

    --
    public class null extends java applet { System.out.print ("Tabula Rasa"); }
    1. Re:Seems interesting... by $RANDOMLUSER · · Score: 1

      Why does your Applet write to the standard output?

      --
      No folly is more costly than the folly of intolerant idealism. - Winston Churchill
  10. Books vs Online Docs by lpcustom · · Score: 1

    I try to see people's point as to why they prefer books over technical docs, but I miss the point totally. You buy a book to learn about the computer you are using or the OS you are using? So where do you read it? In bed? I guess you could but it's not a story it's a book to teach you how to do something on the computer. So you'd be better off if you were in front of the computer while reading it. That way you can have hands on experience with the subject matter. If I'm sitting at the computer reading a book I may as well be reading the documentation or at least a PDF version of the book. Right?

    --
    Beer! It's what's for breakfast!
    1. Re:Books vs Online Docs by Stween · · Score: 1

      It's like a bootstrap mechanism. To learn to use the computer while you're using it is useful once you have some useful skills tied down. Without those skills though, hardcopy outwith the computer helping you gain those skills is entirely useful.

      Personally, I tend to follow your approach, but it's sometimes nice to have one less thing cluttering up your screen, by marking a few useful pages in a book on your desk. I also can't stand reading large amounts of text (perhaps to be found in your PDFs) on-screen. I have to print select sections of those out.

    2. Re:Books vs Online Docs by rufus_sd · · Score: 0

      And for people like you, this type of book would be a complete waste of money. Some people like to have hard copies for reference. They like glossaries, and having a somewhat authoritative source (the author in this case) telling them how to solve their newbie problem. I love the web, I love google and I love built in docs. (I programmed in Java for years just because of the kick ass API) But at the same time, I have 100 computer related books on my book shelf becase I enjoy reading without glare on a monitor, and because my attention span always redirects me to clicking on those ads about punching monkeys to win a prize.

      Some times when I know very little about the topic (when i get in over my head on something or try something for the first time) I am not even sure of what to type for an effective google search. And when i do, i end up with endless message boards where users have the exact same problem as me but no one has responded.

      Books are great as an overview, assembling the contents of this book through google searches would take me a long time. Plus, some of us do read computer books in bed :)

    3. Re:Books vs Online Docs by lpcustom · · Score: 1

      Well, I see that point. I think that in that case, though, I'd just need the first chapter or so. I wouldn't need the whole book. Maybe just a pamplet to get me started. I mean, according to the review, the first chapter tells the reader how to use "man" and "info". Why can't people write books like that? Or pamplets even. They could sell them for 2 bucks instead of $40-100. I mean I could sit down and write 1000 pages. Does that mean I need to? No, not really. Everything I need to know is in the first chapter of that book. I may be exaggerating a bit. :)
      I do tend to read everything on my computer though. No newspapers, no books anymore, it's all on my PC. I spent the money I would have spent on those books on a 21" flat CRT on ebay ($76). Less eyestrain for me. Though it was a backstrain to carry.

      --
      Beer! It's what's for breakfast!
    4. Re:Books vs Online Docs by Anonymous Coward · · Score: 0

      Books are sexy. Your huge cinematic monitor, no matter how high the resolution, is not.

      Our academic system has instilled in us the belief that, to do any serious learning, you obviously need a thick book, and you need to read it.

      Furthermore, there's ambiance. Your directory full of PDF files won't impress anyone. A shelf full of books, does. ;)

      Plus, I don't want to disturb anyone, but I do some of my best thinking on the crapper. One can easily take a book with them to the john, without looking like an unhinged loon. You have network access in your bathroom, you say? Then yes - you are, in fact, an unhinged loon.

    5. Re:Books vs Online Docs by lpcustom · · Score: 1

      Haha I forgot about the other "office/library". My bathroom has Maxim and Stuff magazines, a perl book, a VB book, and a C++ book. I will say that the perl book is actually just a printout of a pdf though. hehe

      --
      Beer! It's what's for breakfast!
    6. Re:Books vs Online Docs by blu3+b0y · · Score: 1

      Don't knock a book. Tactile and spatial memory is useless for PDFs and man pages.

      For many of us, the physical format actually helps with recall. When I'm learning a new system or tool, being able to recall that the command I need is described close to the middle of the book and has a big bolded red header on the facing page is very handy.

      Sure, if you already know you need a particular command, man pages are great. But if you have no idea what the command is called, how the hell are you ever going to find it? Random typing? Searching /usr/bin?

    7. Re:Books vs Online Docs by lpcustom · · Score: 1

      I used autocomplete, when learning Linux. Type "a" hit tab, list all the commands. Type man "command".

      --
      Beer! It's what's for breakfast!
    8. Re:Books vs Online Docs by blu3+b0y · · Score: 1

      Sure, but what if what I want is something like "less" or "nano"?

      Those aren't even remotely intuitive names.

      Using autocomplete is the same is listing /usr/bin, essentially, and useful only if you can remember the command name if you see it, or if the command is usefully named.

      Sadly, that is not a common practice with legacy shell commands.

    9. Re:Books vs Online Docs by WuphonsReach · · Score: 1

      1. A good reference book is not just a regurgitation of the technical docs. Technical docs are generally best for answering the "how" question, but horrid at answering the "why" / "what" / "where" questions. Tech docs show you all the pieces, but rarely show you a really good overview of how it all fits together. (And even with printed material, one of my biggest gripes with authors is when they focus too closely on the "how" rather then answering some of the "why" questions.)

      2. I can jot notes in a book. I can leave little sticky-note bookmarks behind. I can highlight stuff that is important or critical to know. I can flip from section to section, while holding my original place with other fingers. I put the book down and instantly pick it up later and begin again where I left off last time.

      3. I can lean back in my chair, put my feet up and comfortably absorb the information in a book rather then read while scrunched over a keyboard. No refresh rates, no fuzzy text, it's a bit of vacation for my eyes after staring at the screen for too long.

      4. Nothing says "too many irons in the fire" to your boss like a stack of 6-12 technical books on your desk. Especially if most of them are half-open, with scribbled notes, and lots of sticky-note bookmarks. Don't forget to have at least 12" of paper printout of HOWTOs, white papers, and other documentation that you've marked-up, highlighted, and jotted even more notes on.

      5. Not all books are strictly "hands-on". Even books with lots of examples, you may find it better to read the chapter as a whole in one go, then go back and work through examples.

      6. Not all technical topics are discussed well online or in electronic format. In addition, you run into formatting issues, where each one is laid out differently (a printed book tends to follow conventions). Non-specific topics like system administration, database design concepts, architecture are generally not well-covered by online formats.

      I've got 4 books on my desktop at the moment. With another stack of 6 or so down at my feet. Not to mention the full bookcase behind me for books that I pull about once a year when something obscure crops up. After 20 years, there's nothing better then having a good book on-hand that you can pull off the shelf for a quick answer.

      (Gods, can't believe I've been doing this for 20 years.)

      My goal over time has been to obtain and read about a book each month. What usually ends up happening is that I hit a thorny issue, plow through 3-5 books all at once (in addition to doing massive amounts of online searches), and then take a few months to slowly plod through the next one. And about a quarter of the books on my shelves were on topics that I was merely idly curious about.

      --
      Wolde you bothe eate your cake, and have your cake?
  11. Re:Wrong, wrong, wrong. by Anonymous Coward · · Score: 0

    Did I miss anything?
    no, i think that about sums it up.

  12. sounds like another book by mrcdeckard · · Score: 1
    sounds a lot like my "unix in a nutshell" book -- which has all commands in reference format, a quick look at programs like vi (which is obviously the best editer), sed, awk, etc. and a look at a few different shells and scripting with them.


    also, i like the, er, pun in the title.


    mrc

    --
    "Physics is like sex. Sure, it may give some practical results, but that's not why we do it." - R. Feynman
  13. A practical guide to Copy & Paste yet another by Anonymous Coward · · Score: 0

    Oh my. That's what I call effective recycling of old material - or "How to create a book by copying and pasting from three of your previous books".

  14. RTFM by Anonymous Coward · · Score: 0

    If the book is anything like some of the people I've tried to get help from it will contain one page with RTFM in giant bold letters and nothing else. People if you want Linux to grow you need to be more helpful to the less tech oriented people.

  15. Tutorial? by kuzb · · Score: 0, Flamebait

    If you're a programmer who needs a tutorial to use an editor, the chances are good that the editor sucks. I love the Vi(m) vs Emacs arguments, because they are both highly unintuative editors that have an oddly steep learning curve where you really shouldn't need one. While I understand that many have some kind of strange love for these editors, I think it's misplaced. These editors were great when they were our only options for a powerful text editor, but they are outmoded by editors which do a far better job of doing what editors should do best: letting you edit text in an intuative and unconfusing manner.

    --
    BeauHD. Worst editor since kdawson.
    1. Re:Tutorial? by Anonymous Coward · · Score: 0

      So what editor do you use? I am looking for power that doesn't have a steep learning curve.

    2. Re:Tutorial? by Anonymous Coward · · Score: 0

      Vim/emacs are meant to be very powerful tools in trained hands, it's obvious that an untrained user finds them unintuitive and confusing. Yes, there are other good editors more intuitive to the casual user, but in my experience none is as powerful as vim/emacs in trained hands.

      Of course it takes time and patience to master one of them, in my opinion is well invested time but I understand if others prefer easier ways.

    3. Re:Tutorial? by Breakfast+Pants · · Score: 2, Insightful

      Programmers use these editors almost every day of the year. On some days their very existance is manifested in the context of the editor for the entire day. To say that a shallow learning curve is the most important features a programming editor can have is flat out insane.

      --

      --

      WHO ATE MY BREAKFAST PANTS?
    4. Re:Tutorial? by kuzb · · Score: 1

      At what point did I call learning curve a feature? It's not a feature, it's the overall design. These editors have absolute shit for overall design. They should have hired a real UI expert to help them during the conception of these editors. Yes, it's possible to have a good UI in a console. Your program doesn't have to suck just because it's text. If you have to spend a significant amount of time fighting with your editor to get it to do something, you're wasting your time. Wouldn't you rather use that time to write code? I know I would. I am one of those programmers who spends 8+ hours a day with my nose in an editor. I want to focus on my code, not on the tool used to input text in to a file. I don't want an editor like Vi which has a ridiculously stupid command-set, and little or no integration with things that are important to my job. I don't want en editor like Emacs, which is so overkill for things it's insane. I'm sure if you dig deep enough, you'll find the kitchen sink in Emacs. I'm sorry, but I get the honest impression that people only use these editors as a status thing - it sure doesn't have anything to do with productivity or efficiency. and before you say "well, vi makes it so your fingers never need to leave the home row!" keep in mind that vi has such crappy tie-ins to things like CVS clients, and FTP clients that you lose any time saved by it's input method screwing around with commandline crap. No thanks, I'm here to work, not to try to coax the editor in to doing something useful.

      --
      BeauHD. Worst editor since kdawson.
    5. Re:Tutorial? by Goaway · · Score: 1

      If he's anything like me, he uses a GUI editor, because nobody appears interested in making a text mode editor that doesn't suck horribly.

      If I have to edit in text mode, I use pico or nano. They're bad, but nowhere near as painfully user-hostile as emacs or vi.

    6. Re:Tutorial? by Goaway · · Score: 1

      Lame excuses. There's no reason whatsoever an editor can't be powerful to power users and friendly to new users. Emacs and vi, on the other hand, are still stuck somewhere in the early eighties. The rest of the world moved on to better things, they didn't.

    7. Re:Tutorial? by Anonymous Coward · · Score: 0

      1. "UI designers" didn't exist when either of these editors were created.
      2. Vi evolved from ed, and tried to be quick-running on 1970s hardware. Emacs isn't really an editor, it's a collection of editing macros in a LISP environment.
      3. If you want things to be "integrated", you shouldn't go anywhere near *NIX. It'll be bad for both of you. The *NIX philosophy on editors is basically "This is my editor. It edits. What do you mean, 'What else does it do?'!? IT'S AN EDITOR."

    8. Re:Tutorial? by drinkypoo · · Score: 2, Insightful
      Last time I looked (I try not to mind you) emacs did have the kitchen sink. Regardless emacs and vi both have purposes. First of all, emacs is not an editor. If you were expecting an editor, and you ran emacs, you did not get what you wanted at all. Emacs is a common LISP environment. Second, vi is old and fast. More importantly vi came from ed, and ed is a sort of cross between sed and an editor. The creator of vi has gone on record saying that if he knew vi would become so popular, he would never had written the thing, but personally I love vi because it is both fast and powerful. Also, if you need integration of some sort with vi, vim has a quite healthy scripting interface.

      If you want an editor, get an editor. Incidentally vim can be run in a stupid mode where it doesn't use standard vi style modality. You edit, and if you want to issue a command, you hit escape and type it. Most any vi these days will work with arrow keys, too. Finally, vim has a GUI version (gvim) which lets you do pretty much everything from a menu, but shows the keyboard shortcut in the menu, which can help you learn to use vim's more esoteric features. vim is my favorite editor on any system, I use it in braindead mode on windows using gvim and I get all the pretty-printing etc that I want, while using a purely GUI-style app.

      --
      "You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
  16. No Korn? by hal2814 · · Score: 2, Insightful

    What kind of namby-pamby shell scripting tutorial goes over BASH and TCSH scripting and leaves out Korn?

    1. Re:No Korn? by drinkypoo · · Score: 1

      Although it's generally not very hard to get your hands on some kind of ksh, for the most part it's the least available shell around. Everything comes with bash and tcsh, not everything comes with a ksh and there's a handful of different ksh standards you could choose to support when writing one. Anyway, what's ksh got that bash doesn't? Bash is the standard now, the korn shell is an also-ran no matter how great it might be.

      --
      "You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
  17. Long article by Axalon · · Score: 1

    This has to be the longest slashdot article...ever.

  18. Not a Unix book by Arandir · · Score: 2, Informative

    Warning. This is NOT a Unix book. This is a Linux book. If you're looking for a quick reference on Unix commands, text editors and shell programming, so not make the mistake of getting this book.

    It's only about Linux. It says so right in the title.

    </sarcasm>

    --
    A Government Is a Body of People, Usually Notably Ungoverned
  19. And so to OpenDocument by vik · · Score: 1

    Presumably this book will tell me what console editor will edit OpenDocument files in a human-friendly way?

    Won't it?

    Vik :v)

  20. Nedit ! by rumblin'rabbit · · Score: 1
    "nedit" (http://www.nedit.org/) is my fave. Very easy to learn, quite straightforward to customize, nearly as powerful as emacs (for the most common things), and runs everwhere.

    It was perfect for us because many of our users were using clunky old "textedit" on Sun boxes. The adaption time was instantaneous.

    Under the GPL, it's also free, anyway you define it.

  21. lunadevelopment.com by Anonymous Coward · · Score: 0

    Congratulations on your Terrarium award, but the link on the Luna home page appears to be dead...

    http://64.201.37.243/Terrarium/charts/default.aspx

  22. What's wrong with info manuals? by RAMMS+EIN · · Score: 1

    ``Except that many modern systems that would like to call themselves Unix (or Unix-like) don't ship man pages. They ship info pages.''

    You say that as if it is a bad thing. What's wrong with info manuals? The way I see it, info manuals offer useful extra features compared to manpages (hyperlinks!). I'd rather they shipped the docs as HTML and let me use my own browser instead of GNU info, but I don't see anything fundamentally wrong with info.

    As far as the quality of info manuals is concerned (other posters have commented on that), I think that the info manuals for most GNU software easily beat the average manpage on that front.

    Finally, I have to take issue with your statement that modern Unix systems ``don't ship man pages''. Every system I've worked with has manpages, and I rarely run into situations where I want to open a manpage and it doesn't exist. Seldom do I have to read any documentation besides the manpage to get the information I need, which attests to the quality of the pages.

    Seriously, I don't see what you're complaining about.

    --
    Please correct me if I got my facts wrong.