Please create an account to participate in the Slashdot moderation system

 


Forgot your password?
Close
typodupeerror
×
Programming Books Media Operating Systems Software Unix Book Reviews Linux IT Technology

Linux Programming by Example 119

Posted by timothy from the one-by-one dept.
Simon P. Chappell writes "Linux programming is the C Programming Language. Elaborating a little, Linux programming is C, with the GLIBC library and the POSIX standard API. Even a language as powerful as C needs libraries and to get the Holy Grail of cross-platform portability, it's necessary to have them standardised. The POSIX API is that standardisation and Linux adheres to it very well (opinions from those litigious folks in Utah aside). For those of us who already know C, Linux Programming by Example sets out to teach you the rest in a step by step, helpful, relaxed and incremental manner."
Linux Programming by Example
author Arnold Robbins
pages 687 (21 page index)
publisher Prentice Hall
rating 10
reviewer Simon P. Chappell
ISBN 0131429647
summary An exellent tutorial for real-world Linux software development

What's To Like

There are many things to like about this book (over and above the fact that page 118 has my all-time favourite UserFriendly cartoon on it :-). Linux Programming by Example (LinuxPbE hereafter) takes a steady, incremental path through the concepts required to write software that can effectively interact with the Linux environment.

It is a truism many of us have proven multiple times in our lives that one of the finest learning tools available to programmers is to read and grok good, working code, written in the language that we are learning. LinuxPbE takes this philosophy and walks you through actual example code from various Unixes and Linux. The first part of the book, specifically chapters one through six, covers all of the aspects of Linux programming necessary to understand the Unix V7 ls program in its full glory in chapter seven. I feel that this approach works very well.

Part two dives into processes, walking us through creating them, managing them, communicating with them by using pipes and sending them signals. A few other general topics are included for completeness. Part three then covers the art and tools of debugging in fairly substantial detail.

All the code in the book is very well laid out, with line numbers provided to the left, and comments (in a small sans-serif font) on the right-hand side of the code. This is a very readable combination that is enhanced further by the fact that at each logical division, an explanation is given of the design and implementation used by that section.

I can't resist admiring the addition of the essay "Teach Yourself Programming in Ten Years" by Peter Norvig. This is a classic exploration of the effort needed to attain mastery of any skill, concluding that the minimum length of time required is ten years. The inclusion of this article, to me, speaks well of the author and his understanding of the learning process. One can only hope that those learning from this book will come to the same understanding and realise that the book is the start of their journey to mastering Linux programming.

What's To Consider

Nothing notable.

Summary

If you want to learn how to do this stuff for real, then this book will get you started. As "Teach Yourself Programming in Ten Years" explains, no book is going to cause you to become an expert in 24 hours, 24 days or even, perhaps, 24 months. That said, this book will be useful for many of those ten years, so run or surf to your favourite bookstore and purchase it now.

You can purchase Linux Programming by Example from bn.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.

Linux Programming by Example More

Linux Programming by Example

Comments Filter:

  • I do most of my coding by example (Score:3, Funny)

    by Anonymous Coward on Tuesday April 27, 2004 @02:12PM (#8986707)
    Cutting and pasting makes things really easy.

  • Finally. (Score:5, Funny)

    by KimiDalamori ( 579444 ) on Tuesday April 27, 2004 @02:14PM (#8986737)
    Now all we need is a "Linux Documentation Writing by Example" Then we could tell people WTFM instead of RTFM. =)

  • Bookpool! (Score:5, Informative)

    by jargoone ( 166102 ) * on Tuesday April 27, 2004 @02:18PM (#8986765)
    This particular book is currently out of stock there, but I just thought I'd mention one of my favorite sites, bookpool.com. This particular book costs 15% of the list ($6) less than Barnes and Noble. They have great service and fast shipping (often free if you purchase enough).

    No affiliation whatsoever, just thought I'd share.
    • When I was in school - I would do a lot of comparison shopping for books- but bookpool had the lowest price so frequently that I quit looking around and just went straight there.

      I saved tons of money over buying them from the school book store.

      • Re:Bookpool! (Score:4, Informative)

        by fingusernames ( 695699 ) on Tuesday April 27, 2004 @02:32PM (#8986912) Homepage
        Yeah, I started using Bookpool when I was in college, around 92 I believe. Whenever it was, it was before it was a web site or had a domain or was even a company. "It" was just a mailing list, you'd say what book you wanted, and when enough wanted it, they'd go for a group deal from the publisher. It has always had the best prices. For technical books, there is simply no need to look anywhere else.

        Larry
        • Oh yeah, well I started using bookpool when the list was maintained by carrier pidgeon, and you didn't get a book at all, you had to watch the western sky for smoke signals. You could only get about one page per day, though.

    • Well, according to AddAll.com's price comparison for this exact book [addall.com], it's still cheaper at Amazon than bookpool, AND it's in stock.

      --

  • automake, autoconf, .src.rpm, ... (Score:5, Interesting)

    by Speare ( 84249 ) on Tuesday April 27, 2004 @02:21PM (#8986803) Homepage Journal

    The common meta build tools can be a nightmare to learn all at once.

    • autoconf
    • automake
    • patch files
    • .spec and .src.rpm
    • .deb
    • -devel packages vs user packages

    While these are not essential to the beginning developer, having a chapter which covers the background, the problem, the solution and the practice of each of these "meta" tools would be really useful to get new developers going. They don't have to be covered in detail, but really honestly understanding WHY a project might be using a given meta build tool can help more people get involved.

    • Re:automake, autoconf, .src.rpm, ... (Score:5, Interesting)

      by ron_ivi ( 607351 ) <sdotno@cheapcomp ... m ['ces' in gap]> on Tuesday April 27, 2004 @02:30PM (#8986891)
      Indeed. Did you guys ever check out the GNU/HelloWorld [gnu.org] program?

      It's A 380K Tar file! [gnu.org] with over 2000 lines of C code.

      The first time I thought it was a parody, but it's really an insightful look at Internationalization [gnu.org], cross-platform build environments, and other things important to free software. I didn't RTFB that was reviewed, but I hope it goes into these important topics as well. I think this emphasis on coding standards that value the less visible aspects of software such as build environments, internationalization, etc is one of the big advantages of open source.

      • Re:automake, autoconf, .src.rpm, ... (Score:4, Funny)

        by TomorrowPlusX ( 571956 ) on Tuesday April 27, 2004 @02:40PM (#8986972)
        Notice however, that in the grand style of old: it even includes a mail reader.
      • Sorry, that "Internationalization" link was broken (both on their site and my posting).

        The correct link for GNU internationalization coding standards [gnu.org] is here.

      • The first time I thought it was a parody, but it's really an insightful look at Internationalization, cross-platform build environments, and other things important to free software.

        This is why you see so much interest in moving to higher level languages for application development, ones with large standard APIs that include easy internationalization support, among other things. The Java and Mono/Pnetlib/.NET platforms make it easier to accomplish this with much, much less code, and without having to wo

      • Now come on. This is easy to criticize without further investigation, but there is some sense to it.
        First off, it's not intended as a real program but as a sample template from which to build other applications off of in the way that complies with all the standards.
        Second, there is a certain amount of overhead for any well-documented project that accounts for multiple runtime environments. In this case, the overhead greatly outweighs the content because the content is intentionally insignificant. For any re

    • Re:automake, autoconf, .src.rpm, ... (Score:5, Informative)

      by tcopeland ( 32225 ) * <tom AT thomasleecopeland DOT com> on Tuesday April 27, 2004 @02:40PM (#8986978) Homepage
      There's a good book on the auto[blah] part of that - it's GNU Autoconf, Automake, and LibTool [redhat.com].

      It gives a good overview, as well as some extras - i.e., chapter 21 - "Writing Portable Bourne Shell".
      • Actually i started reading until chapter 8 and i must say that it's kind of confusing for someone new to all these tools...(and i agree with some of the negative comments made by people on amazon about it..)
        It'll probably be worth a read later, but for now i need some practical examples.

    • Re:automake, autoconf, .src.rpm, ... (Score:1, Interesting)

      by Anonymous Coward
      The common meta build tools can be a nightmare to learn all at once.

      This is exactly why my philosophy is that if you cannot simply type "make" and have the damned thing build on all systems you are interested in supporting, you are just a lazy bastard.

      The need for a configuration script should be giving you a hint that you've done something wrong. The packages that actually require this level of complexity are extremely few and far between. Most configure scripts I've seen are completely superfluous, a

  • Litigious folks? (Score:4, Funny)

    by Fjord ( 99230 ) on Tuesday April 27, 2004 @02:24PM (#8986825) Homepage Journal
    I thought the appropriate google bomb was litigious bastards [thescogroup.com].

  • IP violation (Score:4, Funny)

    by Anonymous Coward on Tuesday April 27, 2004 @02:24PM (#8986826)
    This is Darth McBide here - I don't often make it a habit of stopping by Slashdot and I have promised myself to take a shower wafter posting this message.

    To the point, I would like to bring it to your attention that any "Linux Programming by Example" would unavoidably be a violation of our broad reaching IP. For reasons that are quite beyond anyone here we cannot tell you the exact contents of our IP so how the heck are you going to know when your examples are going to tread on our property? So please take my advice and refrain from publishing anything that could trigger another lawsuit...
  • even a language as powerful as C.

    Can we mod the original article as +1, Funny?

    • Re:The Power of C? (Score:3, Insightful)

      by Angst Badger ( 8636 )
      I think you are confusing "powerful" with "high level". C is an extremely powerful language, second only to assembly, in that you can write programs in C to do anything within the capabilities of the underlying hardware. The tradeoff you make when using a relatively low-level language is that many common tasks are a pain in the ass, memory management being one of the obvious examples. But the other side of that tradeoff is that higher level languages make common tasks trivial at the expense of rendering cer
      • A friend of mine is writing OpenGL programs but he needs these programs to be really fast, that's why he's using C, and memory management is the heaven for him: you can make copies of structures ten times faster than any other language, it's like using assembly language to write a faster algorithm.

        You can write portable applications with Java or Ruby (I hate Python ;) but if you need optimised code, C is the best thanks to its relatively low-level.
    • I have heard of people programming GNULinux systems in languages other than C. I myself have used C++ and Python to write industrial applications on GNU/Linux. Each such program used POSIX C libraries underneath. I can't think of any program I would write on GNU/Linux that I would voluntarily choose to write in C. C is "the language for Linux" only if you only write kernel code. The kernel maintainers have enforced this restriction not because C is powerful, but rather because it is not powerful, and th

    • double the_power_of_C = pow(x,299792458);
  • I haven't seen the book, but I checked some examples [phptr.com] from the book.

    I can see the following "problems" with some of them (if I am wrong, someone please correct me):

    ch02-printenv.c:

    #include <stdio.h>

    extern char **environ;

    Shouldn't there be a #include <unistd.h> after the #include <stdio.h>? The extern variable environ is available only if unistd.h has been included. While I am talking about this example, it could have used int main(void) instead of ...(int argc, char **argv) (like

    • The above is how you do it. See the 2nd edition
      K&R book, generally considered the main book for
      the ANSI C standard. The above works for C99 and
      C++ as well.

      Leaving out the prototyle, as in "main()", is
      also acceptable. It's gross though, and gets you in
      a bad habit that will lead to loss of type-safety
      when using a C compiler.

      Here you go again:
      int main(int argc, char *argv[])

      (and don't think about changing the names
      either, because that's not how K&R did it)
    • Shouldn't there be a #include after the #include ? The extern variable environ is available only if unistd.h has been included.

      Nope. unistd.h declares extern char **environ, so if you do not #include that header, your code needs to declare the variable. The example program does that, so this is OK in this case.

      I would argue that it's never very good practice to declare by hand things that are declared in header files, because the implementation can change -- witness the problems caused recently when er

      • Re:example code (Score:3, Informative)

        by aridhol ( 112307 )
        Read that site again. You'll find that int main(void) is legit, it's void main(void) that they don't like. And, according to the C standard, it's one of the two legal signatures for main (the other is int main(int argc, char **argv)).
      • You should never use int main(void).

        Surely you meant void main instead of int main? Yup, you are correct. It should not be cast to unsigned long, however.

        Then how should it be done in C89? C89 does not define a format specifier for size_t objects. All it says about size_t is that it's an unsigned type.

  • I am the POWER OF C. You cannot stop me!
  • DOS-heads gloating to each other in front of an Amiga calendar.

    I find that so incredibly weird, my head might implode...

  • re "Teach Yourself Programming in Ten Years" (Score:3, Informative)

    by kclittle ( 625128 ) on Tuesday April 27, 2004 @02:50PM (#8987081)
    I've been programming for 30 years. I recently discovered Python. I'm ass-deep in the uglyness of XML. I'm getting comfortable with Linux, beginning to understand where it's like *nix and where it's not. I'm reading up on .NET; some of it's new, some of it's borrowed, some of it's ugly, some of it's pretty neat. I'd like to get a chance to play with Erlang or ML.

    In short, I am *still* learning, and there are areas I've not even scratched. And I'm having a ball! Ten years? Heck, it may take me fifty!

    • Do you think this is linked to the state of the industry? I mean, does anyone have enough time to truly *master* a language anymore? Using the analogue of a master craftsman e.g. a cabinet maker, they would spend all their life working with tools which only very very very rarely change.

      In the 4 years I've been programming *properly, I've used Delphi, Java, C, C++ , Qt and SQL. I am nowhere near knowing all there is to know about any of them. I'm sort of worried that I'll never really be able to _master_

      • Re:re "Teach Yourself Programming in Ten Years" (Score:4, Insightful)

        by bani ( 467531 ) on Tuesday April 27, 2004 @05:41PM (#8989871)
        Nobody masters a language anymore. You master _techniques_. Languages are just syntaxes to implement those techniques.

        To put your analogy to use, there's really only so many ways (techniques) to build a cabinet. The different programming languages would be the different tools you use to apply those techniques to build a cabinet.

        The nice thing about learning different languages is it often reveals to you new ways of doing things, which you can then apply to languages you already know.

        You'd do well to learn Perl or PHP, btw.
        • I've actually written a couple of quick and dirty Perl scripts to convert cds to ogg and wma to ogg. Same with PHP, a couple of trivial snippets on my website, but not much else. :o)

          I know what you mean about techniques, me and my housemate are always saying this, once you get to grips with concepts, you can pick up language syntax after the fact. But jumping around between languages with these generic techniques, I can't help thinking that very few people will ever know *everything* about a language, h
          • A language I'd like to learn, for the reason you mention, grokking new ways of doing things, is Lisp, having heard the evangelism on /. :o)

            Read a book like Structure and Interpretation of Computer Programs [mit.edu] (SICP). Not only does it teach you ways of doing things, it also teaches you ways of thinking about and analyzing those things, i.e. it should increase your understanding of the languages you have to work with. The biggest lesson the more academic languages have to teach has little to do with the lang

  • What *I* would like to see... (Score:4, Insightful)

    by dmomo ( 256005 ) on Tuesday April 27, 2004 @02:55PM (#8987208)
    Is a 'real world' book on programming for Linux for people who already know how to program. I would buy this book in a heart beat. Let me explain. I know how to program already, and for the most part, what I would be follow ANSI specifications, and should compile uder LINUX. What I would like to see is a book that would explain how to properly write a program for the linux desktop.


    It would explain how to work nicely with KDE and GNOME and what the differences would be. Also, how to make a robust applicaiton that is easily integrated into both environments. It would explain QT v. GDK. It would explain what I, as a programmer should do to make my application work well with others. It would explain how to make a nice installer. How to detect required packages, What command-line options are standard, what API and hook functions should be available.


    Instead of "Learning to Program using LINUX", it would be "Learning to Program FOR LINUX". I would like to know what conventions exist so I would not try to reinvent the wheel.


    Most of this is freely available information that is easy enough to find already. But, I would be willing to pay for a one stop shop that would get me started in the right direction.


    I have yet to see a book that would be a good getting started guide, and then, a good reference. For now, most projects I start by tinkering and prodding, (which is good too), but I would love to create more powerful applications.

      1. Is a 'real world' book on programming for Linux for people who already know how to program. I would buy this book in a heart beat. Let me explain. I know how to program already, and for the most part, what I would be follow ANSI specifications, and should compile uder LINUX. What I would like to see is a book that would explain how to properly write a program for the linux desktop.

      It looks like you're interested in about a dozen books. There's a lot of variety out there!

      • I've never seen a good GNOME book that tells you how to do all sorts of fun stuff like write Nautilus shell extensions, do Bonobo stuff, write filesystem filters, add Evolution plugins, and do drag-and-drop the right way.

        Most of them stick to Gtk+, with a bit of touching on the basics of the GNOME UI, but nothing that really delves into how to make it all work together.
          1. I've never seen a good GNOME book that tells you how to do all sorts of fun stuff like write Nautilus shell extensions, do Bonobo stuff, write filesystem filters, add Evolution plugins, and do drag-and-drop the right way.

          That's book #1. Book #2 would be for KDE.

          Q. With the consolidation happening through Freedesktop.org standards, does that include API or is it mainly file conventions, cut-and-paste, and a few special widgets/add-ons?

          Honestly, I don't know.

    • Might not hurt to learn how to type and spell too. Not to mention grammar.

  • Uninformed article submission. (Score:1, Insightful)

    by Anonymous Coward
    "Linux programming is the C Programming Language. Elaborating a little, Linux programming is C, with the GLIBC library and the POSIX standard API."

    For Linux kernel programming the logical choice might be C, but the article makes it sound like that's the only way to program on Linux.

    If you're a commercial programmer, chances are that C++ is more useful to you (shock, horror - C++ is not C). And I would recommend Python [python.org] for higher level programming (and also for beginners to the programming world).

  • Linuxosity (Score:5, Insightful)

    by Brandybuck ( 704397 ) on Tuesday April 27, 2004 @03:51PM (#8988251) Homepage Journal
    Go grab a "Linux" program at random. Any "Linux" program. Cervisia, GIMP, Emacs, bash, Xmms, etc. Funny thing, they all build and run flawlessly on Solaris, FreeBSD, IRIX, etc. Why? Because they're NOT "Linux" programs!

    Unless you're writing stuff that depends upon a Linux kernel, you're not doing Linux programming, you're doing standard Unix programming. glibc is nothing more than GNU's libc. And libc is pretty damned standard.
  • first time i`ve read it as "Teach Yourself Programming in Tears" 0.o Ain`t that true ?
  • Coincidentally, I'm getting close to buying books on this very subject.

    Can anyone say how this book compares to Advanced Programming in the UNIX Environment by W. Richard Stevens? I was pretty much ready to buy it today.

    the Stevens book [bookpool.com]

    Thanks!

  • X is Y (Score:2)

    by Tom7 ( 102298 )
    C is not the only programming language that works on linux. If it were, I sure as hell wouldn't use the OS.
  • I like to read in the bath-tub. Obviously overly big books are to heavy to read this way. This book is sized well. I made it through the first two chapters in todays soak. Course its not just size... the book has to hold my interest too. Found it on the shelf at my local BN. So far, so good... recommended. Soap optional.

Slashdot Top Deals

HELP!!!! I'm being held prisoner in /usr/games/lib!

Close