Review:Beginning Linux Programming 67
Beginning Linux Programming | |
author | Neil Matthew & Richard Stones |
pages | 710 |
publisher | Wrox Press |
rating | 8/10 |
reviewer | Kurt Gray |
ISBN | |
summary | A fair time worthy of your UNIX programming virginity. |
Hark Ye Newbies, the Clue Phone Ringeth!
The trees felled to print this book died for a worthy cause: to
entice more programmers to hang out at Camp Linux, especially newbie programmers.
Our two friendly co-authors, their three editors, and a small army of technical
reviewers and other hangers-on, will gently take your quivering little
hand and whisk you away into the enchanted forests of shell programming,
curses, terminals, file I/O, pipes, sockets, shared memory, DBM files,
Tcl, Tk, HTML, CGI, gdb debugging, and some other crazy places that would
scare your Mom if she ever found out. The descriptions of each topic are
clear and almost every page includes a tasty morsel of sample code, constantly
assuring that reader that even drooling idiots like you can write real-world
UNIX applications in short time.
Dropping the "L" Word:
Fortunately the content is not biased toward any particular distribution
of Linux, but in fact it's not particularly biased toward Linux either.
I am hard-pressed to find any part of the book that can not be applied
to UNIX in general, so I think a more appropriate title for this book would
be "Beginning UNIX Programming", but I suppose the drawbacks of
doing so would mean 1) whining tech journalists would complain of the lack
of Linux programming books because they didn't bother searching under "UNIX
programming", and 2) Linux is a flavor of UNIX anyway so you may well teach
newbie programmers the UNIX way of doing things.
Perspective:
What I'm reading here is the actually the third printing of this
book, circa 1997, (first printing in 1996) and many things have happened
in Linux development since then so unfortunately there's no mention of
GIMP, GNOME, Gtk, KDE, Qt, MySQL, Mesa, WindowMaker, and other areas that
currently hold the interest of so many Linux hackers. And true, perhaps
these topics too advanced for a book called "Beginning Linux Programming"
but the book does attempt to touch upon all aspects of Linux programming
so why not say a little bit about the APIs that are hosting the coolest
parties.
What's Good:
- Very comprehensive. It would be hard to read this book and still be confused about UNIX architecture.
- Clear examples. Unlike so many programming books where the example code spools on and on for pages, the examples in this book are divided into easily digestible bite sized code snippets, separated by block of text to explain what's going on every step of the way.
- Quick guides to common tools: This book explains the simple yet non obvious commands every UNIX programmer has become familiar with: gcc, make (and Makefiles), gdb, patch, diff, tar, cflow, cxref, indent, lclint, etc. It takes care of most of the questions you'll find posted in comp.os.unix.programming newsgroups.
- Bonuses: It seems to me the authors did not have to discuss topics such as using DBM databases, HTML authoring, and CGI programming in this book, but they do so anyway which makes it all the more harder to keep this book out of arm's reach.
What's Bad:
- PERL, anyone? There's a whole chapter devoted to Tcl and yet only 2 pages devoted to a little something, maybe you've heard of this thing, called "perl"?!
- Open Source, anyone? Fails to reiterate the most valuable asset of Linux which pertains to programmers: it's (almost) entirely Open Source. The code is all there right under your nose! Feel free to browse through it and tell the developers what you think. And sure you could spend many weeks writing your own special application but chances are someone out there has already started an Open Source project to develop exactly what you need. That's what set's Linux apart from so many other flavors of UNIX is the prevailing code license: "GNU's not UNIX!".
- A little bit dated: Since its current printing is from 1997, there's no mention of the newer APIs common in Linux these days (GNOME, KDE, etc. etc.).
- Guilty of declaring fixed-size string buffers: Most of the C code examples reinforce bad habits such as feeding external data directly into fixed-length character buffers. Some examples should have titled "How to Make A Core Dump File". I don't think you can say enough to persuade C programmers to consider the stability and security of their applications. You may accuse me of nit-picking here, but I thinks its best to teach programmers while they're young so to save them a major rewrite later on.
Overall:
It's a keeper. I think even the seasoned UNIX programmer would find it useful due to the variety of topics covered therein. Handy for answering the simple questions like "How I read/write to a DBM file again?" This copy is staying in my office bookshelf.
Pick this book up at Amazon.
Table of Contents:
Chapter 1: Getting Started
What is UNIX? What is Linux? GNU, Free Software Foundation, The C Compiler,
C header files and libraries, UNIX philosophy
Chapter 2: Shell Programming
What is a shell? Pipes and redirection, shell as a programming language,
shell syntax, example app: audio CD collection cataloger
Chapter 3: Working with Files
UNIX file structure, System Calls and Device Drivers, Library Functions,
Low-level file access, Standard I/O library (in C), File and Directory
Maintenance, Scanning Directories, Errors, Advanced Topics (file descriptors
and memory mapped I/O)
Chapter 4: The UNIX Environment
Program arguments, Environment variables, Time and Date, Temp files,
Host information, Logging, Resources and Limits
Chapter 5: Terminals
Reading and writing to the terminal, the terminal driver and interface,
the termios structure, terminal output, identifying the terminal type,
detecting keystrokes
Chapter 6: Curses
Compiling with curses, Basic curses features, keyboard input, multiple
curses windows, subwindows, the keypad, color, example app: The CD audio
collection using a curses interface
Chapter 7: Data Management
Managing memory, memory allocation, the NULL pointer, lock files, deadlocks,
databases (dbm), Example app: The audio CD catalog using dbm
Chapter 8: Development Tools
The make command and Makefiles, Source code control (RCS, SCSS), writing
man pages, making patches and tar files
Chapter 9: Debugging (C code)
Types of errors, code inspection, using gdb, more debugging tools (ctags,
cxref, cflow, prof, gprof, lint) Assertions, Memory Debugging (ElectricFence,
purify, Checker)
Chapter 10: Processes and Signals
Process structure, viewing processes, system processes, process scheduling,
waiting for a process, input and output redirection, threads, signals,
signal sets.
Chapter 11: Interprocess Communication: Pipes
Process types, Sending output to popen, the pipe call, parent and child
processes, reading closed pipes, pipes used as standard input and output,
named pipes: FIFOs, Example: the CD catalog as a client/server application
Chapter 12: Semaphores, Message Queues, and Shared Memory
Semaphores, UNIX semaphore facilities, shared memory, message queues,
queue efficiency, IPC status commands
Chapter 13: Sockets
Socket connections, socket addresses, host and network byte ordering,
Network information, the Internet daemon, socket options, Multiple clients,
the select() function
Chapter 14: Tcl: Tool Command Language
"Hello World" in Tcl, Tcl commands, calculations, substitutions, error
handling, arrays, lists, procedures, Input/Output, Tcl extensions, expect,
[incr Tcl], TclX, networking, graphics, Tk, tgdb
Chapter 15: Programing for X
X server, X protocol, Xlib, X clients, X toolkits, X Window Manager,
the X programming model, the Tk Toolkit, windows programming, configuration
files, Tk widgets, geometry management, inter-application communication,
Example app: a bitmap display program in Tk, Java, X programming with Java
Chapter 16: Programming for the Internet: HTML
What is the World Wide Web, writing HTML, HTML tags, HTML tables, HTML
hyperlinks, serving HTML pages (Apache), Server-side Includes
Chapter 17: Internet Programming 2: CGI
the FORM tag, the INPUT tag, WWW encoding, Writing a server-side CGIprogram,
decoding form data, using perl as a back end to the CGI, returning HTML
to the client, Tips and Tricks, Example app: the CD catalog online
written as a CGIapp in C
Appendix A: Portability
Language portability, reserved names, hardware portability, sizes, byte
order, char, union packing, structure alignment, pointer sizes, moving
to C++
Appendix B: FSF and the GNUProject
The GNUproject and GNUPublic License
Appendix C: Internet Resources
Newsgroups, WWW locations, FTP archives, CD vendors, Linux specific
Appendix D: Bibliography
Standards, other documentation, other cool books not related to computers.
Index
Picture of Tux
Survey Card
Back Cover
Top Surface of My Desk
My Feet
The Carpet
Foundation of this Building
Gravel
Bedrock
Hell
Bedrock
Australia
Space...
Re:Use BookPool, not Amazon (Score:1)
Re:What about portability? (Score:1)
It also clearly explained the different symantics of the select() call between Linux and other UNIXes. That emphasized portability nicely IMHO.
Definitely a great book. (Score:1)
1. Some things are a bit out of place in a book like this - HTML and CGI for one thing. There are ZILLIONS of books on those, and with PHP or mod_perl, CGI is pretty much irrelevant anyway.
2. It's good about emphasizing differences between Linux and other UNIXes. There aren't many, but it did mention some, as in the select() call. Valuable stuff.
3. Its examples are great when you want to get some code quickly cranked out. You can cut and paste a lot of it into your own programs.
Overall, this and _The C++ Programming Language_ are probably the two best non-O'Reilly computer books.
Re:C strings... (Score:2)
Re:C strings...(with FREE code :)) (Score:2)
{
int length = 0;
char ch;
if (*buffer)
{
free (*buffer);
(*buffer) = (char *) malloc (1);
}
else
{
(*buffer) = (char *) malloc (1);
}
do
{
ch = getchar();
if ( ch != '\n')
{
if (ch == '\b')
{
if (length)
{
printf ("\b \b");
length--;
if ( ( *buffer = (char *) realloc (*buffer, length) ) || (!length) );
else
{
return 0;
}
}
else
{
printf ("\a");
}
}
else
{
if (*buffer = (char *) realloc (*buffer, length+1) )
{
(*buffer) [length] = ch;
length++;
printf ("%c", ch);
}
else
{
return 0;
}
}
}
} while (ch != '\n');
if (*buffer = (char *) realloc (*buffer, length+1) )
{
(*buffer) [length] = '\0';
}
else
{
return 0;
}
return 1;
}
/* This one is designed to work with the tty echo turned off... if you have echo turned on, take out the printf()s. For reading passwords and stuff, take out the printf()s _and_ turn off tty echo. */
Re: Yes, it mentions Open Source... (Score:2)
to be legal reasons) but throughout the book
there's no words to encourage readers to get into
Open Source projects and how they can contribute
and reap benefits of Open Source. The Acknowledgements
includes thanks to FSF and GNU but in a sort of
tone as thanking Santa Claus for all the free
stuff -- we don't want new Linux programmers
thinking that GNU developers live in some far off
monastery where they write tools all day for to
atone for their sins in past lives -- GNU is not
just about generousity, it's really about "We're
building Linux because we want it and need it so
if you like it too then why not contribute some
of your code too".
I Disagree (Score:1)
I didn't like "Beginning Linux Programming" for one main reason. It tries to cover way too much in too small of a space. It covers everything from shell scripting to X11 programming(but tells you it's a waste of time and you should use a toolkit) to Tcl/Tk. It covers just about everything, but covers nothing well.
I would suggest you save up and buy a bunch of smaller books from O'Reilly than buying this one. At least you'll get some information that you can use.
Save your money.
Misfit
Linux Application Development (Score:1)
Honestly, this book gives you the skinny on how to program for a unix-style environment. It does NOT cover X, Tcl/Tk, shell or perl. It covers C and how to use the library functions given in an ANSI/Unix environment to a very high level of usefullnes.. Shared memory, semaphores, devices...
It's as good as Programming Linux Kernel Modues book, published by ORA. That one's beside my bed, although it hasn't been openned in quite some time now.
Re:Programming Book (Score:1)
Re:Use BookPool, not Amazon (Score:2)
Re:Out of Stock at BookPool (Score:2)
Re:Programming Book (Score:1)
Re:I Disagree (Score:1)
A much better book is "Linux Application Development" by M.K. Johnson and E.W. Troan.
Re:APUE (Score:1)
Re:What's wrong with Perl ? (Score:1)
Ho, ho, ho, seen Perl 5 ?
More of a type system than SmallTalk.
>> Non-orthoganal syntax
err.. ?? Designed by a linguist to have a natural syntax rather then theoretically perfect but pain to use languages (Pascal, Oberon, ML, etc.) maybe, but that's a plus point for Perl.
>> behaviour isn't well defined
As in what behaviour ?
Seems as well defined as any other cross platform language to me, if not better (Perl is often more portable than Java IMHO).
>> one cannot write correct programs that use stdio thanks to the lack of an _exit().
Say what ?
A million CGI programmers have no problem with stdio.
And if you need _exit(), how about
use POSIX "_exit";
>> Where should I stop?
Perl has its flaws, as does every engineering compromise, but these aren't it...
And remember, this was in comparison to TCL.
Tim
WROX Press (Score:1)
As far as this book over looking Perl, it was probably a choice, not an oversight. There are already several books out there on Perl and many more books that touch on it in relation to other topics. There wasn't a good general "catch all" title out there though... they filled that void. Sure they could have thrown it in, but I don't think that it takes that much away from the value of the book.
A better refresher than tutorial (Score:1)
I will certainly buy the next edition, but it had better continue the style and content. Add new chapters, but don't take away the old.
--
SAMS books and shell programming (Score:1)
First, I would strongly suggest you avoid SAMS books. Like the plague. Sometimes (in the past, and never to be repeated if I can help it) I would buy SAMS books on subjects about which I know a thing or two. In literally every case I've found these books to be full of gross errors. And this doesn't address the shoddy editing that fairly permeates them. Avoid SAMS. Buy O'Reilly (unabashed and uncompensated endorsement -- and no, I don't work for them)!
Secondly, I'd say you ought to skip O'Reilly's bash book if you're learning shell programming. This one title is the most disappointing O'Reilly book I own. It was none too clear, and contained very little in the way of practical examples. It's somewhat useful as a general introduction to using bash, but I don't think it's all that hot at teaching shell programming. IMO Beginning Linux Programming is much better at introducing that -- even though it has just one chapter on the subject. Hopefully O'Reilly will improve their bash book, though.
Use BookPool, not Amazon (Score:2)
Link? (Score:1)
Re:C strings... (Score:1)
fgets( string, n, stdin ) for input
Use
snprintf( string, n, format, params
Use
strncpy( str1, str2, n ) to copy
Etc...
These routines restrict the number of characters that they deal with to n, thus preventing buffer overflow exploits that write pernicious values to the stack and cause your functions to return from whence they did not come.
Also a good habit to
str = (char*)malloc( strlen( s ) + 1 );
instead of just allocating a really big array or something.
Re:Programming Book (Score:1)
Re: (Score:1)
Re: (Score:1)
A little hard on it...? (Score:1)
Admittedly a few of the examples are a bit contrived, and some of the networking section isn't wonderfully explained, but as a quick stepup for people coming from other platforms to Unix, its great...
Re:C strings... (Score:1)
What about portability? (Score:1)
But. . .but. . .the publisher!! (Score:1)
Re:C strings... (Score:1)
You mean though, how to allocate enough space that you don't get overflows.
Can't be done. Any buffer you can allocate can be overflowed if someone tries hard enough.
What you need to do is allocate a certain buffer, n bytes for instance, and read only n-1 bytes from the input. Use an fgets() call to read a certain number of bytes, or if you're reading one byte at a time, simply keep track of how many you've read and when it gets to n-1, write a zero to terminate it and exit.
Being that ram is 'cheap', I usually allocate 4k buffers at a minimum, even for command lines and other 'small' strings. Then I use a strncpy or fgets to read data into the string. Both of these functions have the benefit of reading a certain maximum number of bytes and then terminating, regardless of hitting the end of the string.
I can't see many reasons to make strings dynamic for the most part. Simply allocate as much space as you're going to need in the worst case. (Unless that worse case is a megabyte-long string...)
the book i wish i had 2 years ago (Score:1)
A year ago I bought this book and within a month found it to be worth the price. I still have not found any reference that so clearly and succintly describes the curses/ncurses library. The philosophy of "a little bit of everything" is great -- if you want to learn more perl or tcl or... pick up an ORA book. but this book lets new users (and older users like me) know enough to find out more.
yeah, the typical slashdotter learned all this stuff long ago. and if you develop under unix, this is old hat. but for the windows users who switch over to linux, this is required reading.
Re:Best Linux Book out there (Score:2)
C strings... (Score:1)
Most of the C code examples reinforce bad habits such as feeding external data directly into fixed-length character buffers...I thinks its best to teach programmers while they're young so to save them a major rewrite later on.
I haven't done C programming in a while so I don't remember how to do proper string manipulation. However my g/f is going to take a C class this fall so I need to get up to speed so that I can help her. What would be the correct way to allocate a string in order to allow external input, say from the keyboard? Anybody care to debate fixed size vs. dynamic size strings in C?
Re:No mention of Perl (Score:1)
>
>Types are inferred from their context. treat a scalar like a number and so will perl. the 21st
>century is calling - time to hang up your lisp/ml puritinism - those languages were never any good
>for GETTING WORK DONE NOW. I emphasize that because perl lets you get things done much quicker
>than anything else.
There was a reason for types and that was you'd rather the compiler picked up your bugs, than have to try and work out what went wrong at run time (when your code is treating your string as an integer, or vica versa).
Perl's good for a quick hack, where you're not going to keep the code. But try and maintain it...oh boy.
Cian
Amazing... (Score:1)
Re:Use BookPool, not Amazon (Score:1)
Re:What about portability? (Score:1)
Re:C strings... (Score:1)
It adds the final '\0' only if the source string is shorter than the length parameter.
strncpy(buf, input, sizeof(buf)); should always be followed by
buf[sizeof(buf)-1] = '\0';
Or use strlcpy() if your OS has it (OpenBSD) and you don't need ANSI conformance.
Re:Best Linux Book out there... not just newbies? (Score:2)
new edition coming (Score:2)
by Neil Matthew, Richard Stones
List Price: $39.99
Our Price: $31.99
You Save: $8.00 (20%)
Paperback - 1000 pages 2 edition (September 1999)
Wrox Press; ISBN: 1861002971
This item will be published in September 1999. You may order it now and we will ship it to you when it arrives.
(from Amazon.com)
No Perl? Just you wait! (Score:1)
although there will be at least one chapter on
Perl in the next edition. I know, I've just
finished writing it.
Re:C strings... (Score:1)
You wouldn't believe how many "professional" programmers don't do this. Truncatation is OK (via strncpy) -- not great, but OK. Writing beyond the end of your allocated memory is just horrible. Where I work, we just had several nasty bugs because of things like this:
char buf[16];
strpcy(buf, getenv("SOME_VAR"));
Should be:
char buf[16];
strncpy(buf, gentenv("SOME_VAR"), sizeof(buf)-1);
Of course, if you're using C++, you can avoid the whole issue by using the string class, which holds variable length strings:
string s = getenv("SOME_VAR");
I Agree to Disagree with those who Disagree (Score:1)
>It tries to cover way too much in too small of a space.
This is exactly why I loved it. It explained a huge number of points clearly and concisely, gave a brief code example, and then moved on without making me wade through another hundred pages on a topic I already knew all I wanted to know about. It's an ideal book for someone who likes to grab a book, read it cover to cover to cram a bumch of concepts in their head, have a reference in which it's easy to find exactly the piece of information that they're looking for, and then when they try it themself and it doesn't quite work, they're happy to bring up the man pages to get the rest of the details.
But if you want to have all of the details in the book, if you want a comprehensive treatment of each topic, if you don't need a book to enlighten you about what's possible, but prefer a book where you can look up exactly how to do everything that's possible, then perhaps this isn't what you're looking for.
Does this book have any peers/competitors? (Score:2)
I haven't seen any books similar to this. I only see UNIX/Linux "user" books (installation process, basic utilities, etc) and advanced programming tomes (A-W's excellent "Programming in the UNIX Environment").
I think that this may be the only good "beginning" UNIX programming book out there... if there are others, please tell me what they are!
BTW, I agree with the "this is not a Linux book" comments -- it really is a general UNIX book relabeled to sell better. Which is good, since I'm rather partial to FreeBSD myself :}
Linux Not Unix (Score:1)
First, count how many times UNIX is used, and second threading in Linux has "relatively poor support"!!!
Re:Amazing... (Score:1)
As always, check Best Book Buys (Score:1)
- Jeff
Revision Notification? (Score:1)
New Edition (Score:1)