Slashdot Mirror
Advanced Unix Programming, 2nd Ed.
Advanced Unix Programming (AUP) has been updated to include information relevant to Solaris, Linux, FreeBSD, Darwin and Mac OS X. Rochkind has added more than 200 system calls, according to the preface. But who is the book for?
First off, if you look at the table of contents, you will find that AUP is largely a book on input-output in Unix operating systems. The input-output varies from Basic (Chapter 2) and Advanced (Chapter 3) File I/O to Interprocess Communications (Chapters 6, 7), Network I/O (Chapter 8) and Terminal I/O (Chapter 4). The rest of the book consists of purely informational chapters on fundamental concepts of Unix operating systems (Chapter 1), working with threads and processes (Chapter 5) and signals and timers (Chapter 9).
If you get the impression that this is an academic title, you're not mistaken - if your university has some kind of Advanced Unix/Linux or Unix Networking course, they probably use some AUP material. Note that the book is not a how-to or manual on setting up Apache, Samba, FTP, various filesystems or Jabber servers - it does have a chapter on networking but teaches Unix I/O concepts from developer's perspective only, meaning you have to know C and C++. If you prefer to look at the source code, it's on the author's Web site.
There are two types of readers for AUP: those who start off programming in Unix/Linux, and those who are quite good at it, have read the first edition and are now wondering whether the second one is worth it.
If you are just starting with programming in Unix/Linux environment, don't let the word "Advanced" scare you off. The first chapter is pretty good in getting the reader up to speed with the concepts discussed in the book. It talks about such common tasks as getting the system to tell you what it has in terms of POSIX, getting a Unix box to tell you the date and time inside a C++ application, and counting your app's execution time. In many aspects, the second half of each chapter falls under O'Reilly cookbook format, where you are given a certain task and then provided the source code and explanations of what needs to be done to accomplish the task.
The author also "falls" into the trap of using some quick solutions only to "discover" that they do not work on all the systems. For example, subchapter 3.6.1 Reading Directories first tries to access the contents of the directory via ec_neg (fd = open (".", O_RDONLY) and ec_neg (nread = read (fd, buffer, sizeof(buffer))) only to find out that under Linux the call retrieves unhelpful "*** EISDIR (21: "Is a directory") ***" message. After that we are introduced into proper, not quick and dirty ways, to access Unix directories via opendir(), closedir() and readdir().
From experience, it looks like most of the people I know who own a copy of the first edition of AUP bought it because of its section on Interprocess Communications. The author does indeed provide a great learning and reference resource when in Chapter 5 he takes the reader through Unix processes and threads, explains how fork() works. The simple pop quizzes are there as well. A way to win friends and amuse the opposite sex during watercooler talks is to offer the following example:
void forktest (void)
{
int pid;
printf ("Start of test.\n");
pid = fork();
printf ("Returned %d.\n", pid);
}
Run this example as forktest and you will get a message:
Start of test.
Returned 11111.
Returned 0.
Run this test as forktest > tmp and suddenly the message in tmp file changes:
Start of test.
Returned 22222.
Start of test.
Returned 0.
Why is "Start of test" printed twice in the second example? Warning: the book contains an early spoiler in 5.5 fork System Call
By this point, you probably wonder whether the code examples will work on your system. The author tested the code on Solaris 8, SuSE Linux 8, FreeBSD 4.6 and Darwin (Mac OS X kernel) 6.8. In the preface, he talks about using a Windows box with SSH client to upload the code to the destination systems and run them there.
The book is very convenient to read; the chapter numbering system always gives you a good feel of where you are at. As reading of the entire book is not required, and a lot of people use AUP as a reference, an index containing just functions and system calls is included in Appendix D. Don't know what tcgetpgrp() does? The index will point you to 4.3.4. All the code is printed in monospace font, so it's quite easy to differentiate from the regular text. All the function definitions are boxed with function name, description and signature provided. The signature itself contains comments on what the parameter represents. They also are not saving whitespace on function samples, using the style where each line of source code and each { gets a separate line in text. Overall, more than 1100 functions are covered.
The book is quite practical, too, so don't think of it as pure API rehash. For example, in 8.4.3 (the chapter 8 deals with Networking), you are given the source code for a text-based browser that's written in less than 50 lines of code (although it doesn't quite understand HTML and just dumps everything to standard output).
Overall, if any part of your job description or hobby list includes Unix/Linux development, especially if it's high on that list, this book is a must have. Moreover, looking at the job market defined by keyword "unix", it looks like half the positions include some kind of "Sr." or "Architect" or "Networking" attribute, for which the knowledge provided in AUP would be indispensable.
You can purchase Advanced Unix Programming, 2nd Ed. from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, carefully read the book review guidelines, then visit the submission page.
Well, I'm having trouble getting to the link, so here's the amazon.com page (not a referral link):
Advanced Unix Programming They have 27 used copies, and the book's gotten high reviews.
Because the first printf was automatically flushed after the newline, because it's going to a terminal. Some stdio implementations are like that.
It wasn't flushed in the second example, it would only write out data once there was a full buffer's worth (e.g. 32kb or such), or when the stream was closed. Because it wasn't flushed, both fork()ed copies had this unflushed data in their buffer and both printed it.
I'm sure it scares a few newbies, but it's fairly obvious.
Does my bum look big in this?
That chapter alone tells me to avoid this book like the plague.
I spotted the first edition of this book in my university library when I was doing some coding on FreeBSD. Whilst it didn't have anything specific to FreeBSD it was still a handy reference. I look forward to reading the additions in this version. Perhaps I'll get the university library to order it for me ;-)
My operat~1 system unders~1 long filena~1 , does yours?
okay, I'm not *trying* to troll, but, what with SCO, I'd've thought that they'd do more to separate themselves from UNIX(r).
So you use opendir() to read a directory!
Who knew?!
...in twenty years every other programming book I have will be in it's 123rd edition.
I wonder how well Marc holds up against Stevens.
It's very unfortunate Stevens died so young, his books including "Advanced Unix Programming" are extraordinary.
You stole the following code from SCO did you not?
void forktest (void)
{
int pid;
printf ("Start of test.\n");
pid = fork();
printf ("Returned %d.\n", pid);
}
I'm certain you did. It's code and it can be used in Unix so it belongs to SCO.
How does it compare to APUE?
I have used this book for the past few years mostly as a reference for some of the really hairy stuff/problems that I have sometimes run into.
It belongs on my bookshelf right along with my Unix Network Programming books (Richard Stevens auth).
Or would that be the 10th edition?
Gonzo Granzeau
"Nothing the god of biomechanics wouldn't let you into heaven for.." -Roy Batty
Can't wait to buy this book, go home, and snuggle up to the cozy fire with my Advanced Unix Progamming book 2nd edition.
Nowdays though, my definitive reference for writing portable unix programs is the merged IEEE POSIX and Open groups's Single Unix Specification. Registration is free.
So would this book be worth getting if I already own Stevens' APUE
psst..
Thats offtopic, but not flamebait.
10 bucks says others are struggling with the same fuckin thing.
Oh, and as for IDEALX's LDAP user webmin module, when you configure it and it asks for the "LDAP Admin Username", it wants the fully qualified dn, like "uid=cmdrtaco,ou=homos,dc=slashdot,dc=org".
Of course, like all useful linux utilities, there's absolutely no documentation about it. Now some other dork can benefit from my hours of trial-and-error.
But yay me, after a week of cussing, I know have a half-assed functional equivalent of a 10 year old server technology that MSFT abandoned!
Who needs krb5 and ldap when you got flatfiles and MSRPC, right?
And THAT's advanced unix programming, folks.
I don't need no instructions to know how to rock!!!!
A book that has been considered a timeless classic,
I am an avid book collector who has appeared on "Antique Roadshow" and "Cover to Cover Classics". I consider myself an authority in this matter. I have touched original Guttenberg bibles, been in the presence of the "War and Peace" transcripts, thumbed through the notes of DaVinci...but never, and I mean never, have I stumbled across this true classic! Ebay, Sothebys, 7 Mile Fair in Racine, Wisconsin...NO WHERE have I been able to zero in on this rareity.
I will gladly sacrifice a small fortune to be in same vicinity as this timeless classic known by a few rare collectors as "Advanced Unix Programming, 1st Edition." Extra if it is bound by that cool shiny metal spirally stuff.
With UNIX having been around so long, I wonder how close we are to having a book of just varieties of implementations of "ls", since there are so many hundreds of UNIX scripts, scripters, etc.
stuff |
The author tested the code on Solaris 8, SuSE Linux 8, FreeBSD 4.6 and Darwin (Mac OS X kernel) 6.8. In the preface, he talks about using a Windows box with SSH client to upload the code to the destination systems and run them there.
No testing - or even discussion - under cygwin, MS's native POSIX subsystem, linux-on-windows or MS's unix services for windows?
People need to develop for unix - for windows. All those killer win32 apps end up unix compatible, and future migrations are a snap once you tell your pointy haired boss that his favorite solitaire program is really a unix application running through a compatiblity layer.
So there ya go.
Seriously though, why do people ignore such things? The future is in hybrid systems. Your OS prejudices be damned.
I don't need no instructions to know how to rock!!!!
I had an operating systems class and in it we had a discussion section where we learned various types of system calls, such as forking, mutexes, pipes etc. Our TA for the discussion was an asian grad student and when we learned about fork() he pronounced it "fuck()". It was great learning what happens when you instruct your program to "fuck()". Needless to say, all you would hear was held back laughter from the entire class. For some reason, it never got old, he always found new ways to make "fuck()" really, really funny
"If you are a dreamer, a wisher, a liar, A hope-er, a pray-er, a magic bean buyer
Where do you even start to review?
Um, page 1?
A way to win friends and amuse the opposite sex during watercooler talks is to offer the following example:
I don't think any of the opposite sex will be amused. In fact, I seriously doubt it.
Well.. maybe. Or Maybe not. But Definitely not sort of.
They leave out my favorite example of an advanced Unix programming technique, which is file handle passing. You can actually pass an open file handle from one unrelated process to another.
Sure, it's easy to have two processes open the same file. If it's something like a pipe that exists anonymously, you can still give it to a child process by having it open when you fork. But to pass it to a process that isn't a child? Tougher, but not, surprisingly, impossible. (It involves Unix domain sockets, of all things.)
I generally don't find too many people that know about this, but it can be very useful on occasion. I think it definitely qualifies as an important technique, and the fact that this book doesn't appear to mention it is a strike against it. (Stevens discusses the topic, of course.)
I'm looking for good UNIX programming books that don't hide the ugly reality of porting between different Unix systems. Including shared libraries, threads and siganls, etc.
Now I'm stuck with an older version of the book. Guess maybe I can sell it on Amazon to some tard, but what tard would actually buy the first edition? Guess I'm the tard with an old programming book. Damn it!
It isn't a lie if you belive it.
The old way was to call open() on the directory,
then simply use read() to get an array of structs.
Each struct had a 16-bit inode number and a
14-character filename.
Linux broke support for this, because 32-bit inode
numbers and 255-character filenames would not fit.
Linux would get stuck with DOS-style name mangling
and some sort of inode remapping. Like this:
Linux_i~1.html
(but hey, 14 characters beats 8.3 style names)
I have the first edition and it turned out to be an invaluable (if occassionally outdated) resource in many of the C programming positions I've held. If you program in C on UNIX, you should own this book!
I'm trying to teach myself to set people on fire with my mind... Is it hot in here?
I don't think this new book can compare.
:-(
There's just something wrong with trying
to write a UNIX book while running Windows.
Stevens wrote APUE with *roff macros! FYI,
that beats TeX for nerd value.
Problem is, APUE is getting obsolete.
The first edition of this book ranked up there
with K&R's C book and K&P's unix book as a must
have.
The style is light and engaging, and humorous.
e.g. on the 'new' lseek call there's a footnote:
"The extra letter (l) was available, since
creat was one letter short"
I still have my dog-eared copy which I refer to
from time to time.
HP distributed it with their first Unix systems
in lieu of a an official HP manual.
This 2nd edition adds a Java POSIX library
which is excellent. I am already using it
in production systems.
(Comparison's with Stevens book are a little
unfair as they have different emphases.
Rochkinds is on Unix, Steven's are less on
Unix and more on networking)
termios(3): Sounds interesting enough, though, and everyone else seems to be happy with it. I may check it out.
Assume I was drunk when I posted this.
Firstly I feel I must correct the author on his error in referring to an operating system using the Linux kernel as Linux, instead of GNU/Linux. For the reasoning behing this see here.
Secondly I note that accompanying any book on programming there should be a book on Free Software to educate the programmers of the future as to the importance of Free Software and the evils of supporting proprietary software.
You can read more about the GNU project at http://www.gnu.org/.
It had typographic style. This new one is too fussy. What's with the maze and the yellow paint splash? Looks like a book about home decorating.
Understanding Linux Kernel + Linux Kernel Device Drivers
Those two books gain you an understanding of the linux kernel (and OS concepts in the meanwhile) only rivaled by reading the kernel source (and http://lxr.linux.no/ is the best for that!)
I tried the forktest, and renamed the forktest function to main and ran it. It displays numbers like 731 and the > tmp does about the same.
Am i doing something wrong?
Open Source Java Web Forum with LDAP authentication
italo160.mp3
In institute where I used to work, we had one copy of 1st edition. It was the book where from I learned UNIX programming.
From my friend who still works there, I heard that they had managed somehow to lose the copy. I was so sad, that I decided to buy one. Shipping costs were much larger that cost of the second hand book...
Just when book arived, I heard about new edition!
All I want to know is, would adding this book to my collection be redundant, or would it actually be useful? Given the quality of the late, great Stevens' writing, I suspect the former...
looks like advanced compiling if the author can get that code to run ...
To tell you the truth. I always liked the "feel" of the book.The book looks a lot heavier than what it really is.
I just love the Addison Wesley books.
Think like a man of action, act like a man of thought.
Every hard-core UNIX programmer should know how to
pass file handles between arbitrary processes.
I wonder how much of the "Y2K problem" might have been caused by blindly following the author's code in the 1985 edition (page 51) which assumed the year 2000 was NOT a leapyear.
Richard,
You have to get your karma up if you want your message to be heard. This is the way we do it around here. Never correct slashdotters with low number because they have 5 or 10 accounts with about half of those having mod points at any one time so they can mod-bomb you into submission. Only say things that teenage boys would want to hear, like "Doom3 rülz d00dz!" or "RIAA sucks rocks!". It is also important to pay attention to which catch phrases are currently hip. You don't want to still be saying 'All your base are belong to us' when 'In Soviet Russia' jokes are all the rage. Making jokes about porn gets you modded down unless its really funny and even then always spell porn as pr0n. When you troll, make sure you check that box that says 'Post Anonymously' unless you've built up enough karma to burn. And any bad comments about John Katz is guaranteed a few +1 insightfuls. Well that should be enough to get you going for now.
Good luck with your whorin'.
Liberals call everyone Nazis yet they are the closest thing to it.
Translation: "I don't know how to properly examine the output of make install I do not know how to use which, slocate or find. I cannot understand basic error messages, but that is irrelevent because I don't know how to make proper use syslog anyway."
The only point your entire post has is that the documentation is poor. So fix it instead of whining on Slashdot.