Linux Programming by Example 119
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.
I do most of my coding by example (Score:3, Funny)
Re:I do most of my coding by example (Score:5, Funny)
Re:I do most of my coding by example (Score:2, Insightful)
Re:I do most of my coding by example (Score:1)
If I run xwin on cygwin on my Windows computer, I cannot copy-paste from Windows to a window in X. Just doesn't work.
Re:I do most of my coding by example (Score:1)
Works good here.
just selected your comment in win Mozilla.
Middle clicked in an xterm logged into a remote machine running vi.
started X with
Update your cygwin?
Or select & copy in win (Ctrl+c)
left click the top left corner of a regular cytwin terminal. Select Edit-Paste from the drop down menu.
Cygwin, don't leave $HOME without it!
Best of luck.
(recent install of Cygwin running on XP)
Re:Linux routines (Score:1, Funny)
#!/usr/bin/python
while DarlsWallet:
DarlsWallet -= 699
Lawyer += 699
raise SystemExit, "we're out of money!"
Finally. (Score:5, Funny)
Re:Finally. (Score:1)
What? Where?! (Score:2)
Bookpool! (Score:5, Informative)
No affiliation whatsoever, just thought I'd share.
Re:Bookpool! (Score:1)
I saved tons of money over buying them from the school book store.
Re:Bookpool! (Score:4, Informative)
Larry
Re:Bookpool! (Score:1)
Re:Bookpool! (Score:2)
Larry
Re:Bookpool! (Score:1)
aw crap. I'll stop now.
addall price comparison (Score:2)
--
Re:What Linux needs is VB (Score:4, Funny)
I did manage to get it to compile with C# but I got some weird errors when running it with the
Re:What Linux needs is VB (Score:1)
For everyone who didn't get it, look for the Project David story that was on
Re:What Linux needs is VB (Score:1)
Re:Wow. (Score:1, Funny)
automake, autoconf, .src.rpm, ... (Score:5, Interesting)
The common meta build tools can be a nightmare to learn all at once.
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)
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)
Re:automake, autoconf, .src.rpm, ... (Score:2)
The correct link for GNU internationalization coding standards [gnu.org] is here.
Re:automake, autoconf, .src.rpm, ... (Score:1)
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
Re:automake, autoconf, .src.rpm, ... (Score:1)
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)
It gives a good overview, as well as some extras - i.e., chapter 21 - "Writing Portable Bourne Shell".
Re:automake, autoconf, .src.rpm, ... (Score:2)
It'll probably be worth a read later, but for now i need some practical examples.
Re:automake, autoconf, .src.rpm, ... (Score:1, Interesting)
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)
IP violation (Score:4, Funny)
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...
The Power of C? (Score:2, Funny)
Can we mod the original article as +1, Funny?
Re:The Power of C? (Score:3, Insightful)
Re:The Power of C? (Score:1)
You can write portable applications with Java or Ruby (I hate Python
Re:The Power of C? (Score:2)
Re:The Power of C? (Score:3, Funny)
double the_power_of_C = pow(x,299792458);
example code (Score:2, Funny)
I can see the following "problems" with some of them (if I am wrong, someone please correct me):
ch02-printenv.c:
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
int main(int argc, char *argv[]) (Score:1)
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)
Re:int main(int argc, char *argv[]) (Score:1)
Re:int main(int argc, char *argv[]) (Score:1)
second edition.
Heretics use **argv or **av or *av[] or....
Re:example code (Score:2)
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)
Re:example code (Score:1)
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.
Re:example code (Score:1)
I will use malloc for my examples below, but the same thing could be said fo
You wish this was off topic! (Score:1)
Umm, whats with that user friendly comic. (Score:2, Funny)
I find that so incredibly weird, my head might implode...
Re:Umm, whats with that user friendly comic. (Score:3, Informative)
Re:Umm, whats with that user friendly comic. (Score:2)
re "Teach Yourself Programming in Ten Years" (Score:3, Informative)
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!
Re:re "Teach Yourself Programming in Ten Years" (Score:3, Interesting)
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)
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.
Re:re "Teach Yourself Programming in Ten Years" (Score:2)
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
Re:re "Teach Yourself Programming in Ten Years" (Score:1)
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)
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.
Re:What *I* would like to see... (Score:3, Insightful)
It looks like you're interested in about a dozen books. There's a lot of variety out there!
Re:What *I* would like to see... (Score:2)
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.
Re:What *I* would like to see... (Score:2)
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.
Re:What *I* would like to see... (Score:1)
Uninformed article submission. (Score:1, Insightful)
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)
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.
Teach Yourself Prorgamming in Ten Years (Score:1)
compared to Stevens? (Score:1)
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!
Re:C? you must be kidding (Score:1)
But there are lots and lots and lots of people who code Linux programs in C -- the vast majority of the programs I come across, at any rate. These people surely aren't being coerced into it by some manager. I assume that most of the people writing sophisticated software
Re:C? you must be kidding (Score:1, Insightful)
Re:C? you must be kidding (Score:1, Insightful)
A lot of the open source projects you read about have portability to multiple platforms as a goal, or are system-level software/utilities that really needs to be coded closer to
X is Y (Score:2)
Re:Duplicate Titles on Books?... (Score:2)
bathtub reading (Score:1)