Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 


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

Advanced Unix Programming, 2nd Ed. 143

Posted by timothy from the heavy-eyelids-heavy-lifting dept.
prostoalex writes "Advanced Unix Programming by Marc Rochkind is published by Addison-Wesley this year in its second edition. A book that has been considered a timeless classic, a title that saw its first edition back in 1985 and its second edition almost two decades later, in 2004. Where do you even start to review?" Read on below to see read prostoalex's evaluation.
Advanced Unix Programming, 2nd Ed.
author Marc Rochkind
pages 736
publisher Addison Wesley Professional
rating 9/10
reviewer Alex Moskalyuk
ISBN 0131411543
summary An introduction and guided course through the world of Linux I/O and interprocess communications, with C++ source code provided for your viewing pleasure. More than 1100 functions explained.

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.
This discussion has been archived. No new comments can be posted.

Advanced Unix Programming, 2nd Ed. More

Advanced Unix Programming, 2nd Ed.

Comments Filter:
  • Well, I'm having trouble getting to the link, so here's the amazon.com page (not a referral link):

    Advanced Unix Programming [amazon.com] They have 27 used copies, and the book's gotten high reviews.

  • Does does it print twice? (Score:5, Informative)

    by kyz ( 225372 ) on Thursday April 29, 2004 @05:05PM (#9012422) Homepage
    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.

    • Re:Does does it print twice? (Score:5, Informative)

      by pclminion ( 145572 ) on Thursday April 29, 2004 @05:16PM (#9012560)
      If you want the line buffered behavior even when outputting to non-terminal devices, without having to explicitly call fflush() after every line, you can force the stdout stream into line buffered mode like this:

      setvbuf(stdout, NULL, _IOLBF, 0);

      You must do this before you use stdout in any way.

    • That doesn't explain me why the printf is executed twice whereas it sits BEFORE the fork?

      Isn't the forked process supposed to begin its execution just after the fork() call???
      If so, there should be only ONE "Start of test"...

      Can anyone tell me what's happening?
      • Ok the grandparent post IS explaining it, I was just... reading it with a closed mind...

        The printf IS indeed executed only ONCE, it's the stdio buffer containing the first printf's string that's duplicated by the fork...

        Please forget me and my post...

  • Terminal I/O? (Score:5, Funny)

    by Not The Real Me ( 538784 ) on Thursday April 29, 2004 @05:06PM (#9012429)
    That chapter alone tells me to avoid this book like the plague.

  • Good UNIX Reference (Score:3, Informative)

    by mcx101 ( 724235 ) on Thursday April 29, 2004 @05:06PM (#9012434)

    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 ;-)

  • 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).

    • Re:*NIX (Score:5, Informative)

      by mcx101 ( 724235 ) on Thursday April 29, 2004 @05:10PM (#9012485)
      Don't forget though that UNIX is a registered trademark of The Open Group, so even though SCO has (claims to have?) the rights to the UNIX source code they don't own the name.
    • For the most part, far from it. Granted some Linux users may have gone to alternative systems, the non Linux *NIX is still going quite strong.

      • Re:*NIX (Score:2, Interesting)

        by ydrol ( 626558 )
        Especially as most GNU / GPL / Open /BSD stuff runs on *NIX anyway (often even before it ran on Linux)

        In the corporate server market savings on Linux are minimal compared to Sun etc because of two things:

        1. Server quality x86 boxes for hosting business critical applications can cost as much as Sun / HP Boxes. So no real hardware savings that justify the "risk".

        2. Most companies do not have /dedicated/ Linux admin support skills and need to outsource some degree of support in order to provide that supp

  • opendir() (Score:1, Redundant)

    by hey ( 83763 )
    So you use opendir() to read a directory!
    Who knew?!
    • my programs don't open directories, you insensitive clod!

      % ls -1 *foo | ./my_program

    • 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)

  • Interesting change of pace... (Score:5, Funny)

    by eidechse ( 472174 ) on Thursday April 29, 2004 @05:09PM (#9012464)
    ...in twenty years every other programming book I have will be in it's 123rd edition.

  • Marc vs. Stevens (Score:5, Interesting)

    by jonfelder ( 669529 ) on Thursday April 29, 2004 @05:09PM (#9012473)
    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.

    • Re:Marc vs. Stevens (Score:4, Interesting)

      by eschasi ( 252157 ) on Thursday April 29, 2004 @05:20PM (#9012590)
      Hear, hear. Rochkind is good, but has neither the breadth nor depth of Stevens. It's a damned shame that there's apparently no-one with Stevens' dual skills in programming and writing who can take up his mantle. The review above, while generally complimentary, doesn't sound like Rochkind can replace Stevens.

      And I fondly remember MTS, too.

      • Re:Marc vs. Stevens (Score:4, Interesting)

        by Ankh ( 19084 ) * on Thursday April 29, 2004 @06:21PM (#9013265) Homepage
        On the whole I'd say Marc Rochkind is actually a better writer - it's a lot harder to write a thin book on a topic and still have it be this useful.

        If you're working in C (or C++ I suppose, Oh you youngsters!) on and form of Unix, you probably already have the first edition, or at least have read it. If not, go and get it (or this second edition). Along with The Unix Programming Environment, it's one of the classic texts that's not too large to read, but too useful to skip.

        Liam

    • Re:Marc vs. Stevens (Score:5, Informative)

      by hitchhacker ( 122525 ) on Thursday April 29, 2004 @05:31PM (#9012724) Homepage
      "Advanced Unix Programming"

      I believe you mean:
      "Advanced Programming in the UNIX Environment" [barnesandnoble.com]

      His "TCP/IP Illustrated" volumes 1-3 are also great.
      I havn't read AUP, so I can't compare him to Stevens.

      -metric
    • It is unfortunate - I keep a copy on my desk (actually had two copies before I realized one order was just really late!).

      But he (Stevens) wrote Advanced Programming in the Unix Environment (APUE), not Advanced Unix Programming...I can see buying AUP and getting myself thouroughly confused..."Hand me that copy of APUE, er, AUP, um, the one with the RED stripe on the cover!!!"

      I find it strange Addison-Wesley doesn't include Unix Network Programming Vol 2 (IPC) in its "Professional Computing Series" [awprofessional.com]...APUE,
      • Life would be so much easier if we could just look at the source code...
        See e.g. this [weizmann.ac.il].

        (What you really meant was if we could understand the damn thing, too. At long last. Biochemists are obviously just lazy. :-)

        Anyway, I agree -- the world would be a better place with Stevens still in it, writing books.

    • I have both. Marc first edition was less comprehensive. Steven's second eddition was even better. I haven't see Marc's second edition yet.

  • Copyright infringement (Score:5, Funny)

    by sdjunky ( 586961 ) on Thursday April 29, 2004 @05:10PM (#9012479)
    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.

  • Obvious question (Score:5, Insightful)

    by Florian Weimer ( 88405 ) <fw@deneb.enyo.de> on Thursday April 29, 2004 @05:12PM (#9012510) Homepage
    How does it compare to APUE?

    • Re:Obvious question (Score:1, Funny)

      by Anonymous Coward
      Go to the Quik-E-Mart and see for yourself.
    • Leading question. I hope some gurus answer. I was planning to buy APUE, and I want to know!
    • 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. :-(

    • Re:Obvious question (Score:3, Interesting)

      by maw ( 25860 )
      Good question. One thing that caught my attention was this: Covers the system calls you'll actually use-no need to plow through hundreds of improperly implemented, obsolete, and otherwise unnecessary system calls! I read this as a mild jibe at Stevens; it implied, to me anyway, that it is at least likely to be leaner than APUE.

      A book with the rigour and depth of Stevens without the obsolete stuff (Stevens deliberately includes obsolete calls and functions, and with good reason, but it still can be frust

  • Excellent Reference (Score:4, Informative)

    by muppetsrule ( 734214 ) on Thursday April 29, 2004 @05:17PM (#9012564) Journal

    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).

  • Um... (Score:5, Funny)

    by GoNINzo ( 32266 ) <GoNINzo.yahoo@com> on Thursday April 29, 2004 @05:22PM (#9012616) Journal
    If they were true programers, wouldn't this be the 1st edition? Cause if you start counting at 0...

    Or would that be the 10th edition?

  • Oh Joy! (Score:5, Funny)

    by Sloh_One ( 756526 ) on Thursday April 29, 2004 @05:23PM (#9012630) Homepage
    Can't wait to buy this book, go home, and snuggle up to the cozy fire with my Advanced Unix Progamming book 2nd edition.

  • POSIX Reference (Score:5, Informative)

    by the frizz ( 242326 ) on Thursday April 29, 2004 @05:26PM (#9012653)
    AUP really is a classic. I may buy it just for sentimental reasons, even though I don't need the tutorial introducton to Unix anymore.

    Nowdays though, my definitive reference for writing portable unix programs is the merged IEEE POSIX and Open groups's Single Unix Specification [opengroup.org]. Registration is free.

  • So would this book be worth getting if I already own Stevens' APUE

  • First Edition? (Score:5, Funny)

    by WwWonka ( 545303 ) on Thursday April 29, 2004 @05:32PM (#9012733)
    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.

  • What!? (Score:2, Insightful)

    by stratjakt ( 596332 )
    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 y

  • Fork() (Score:3, Funny)

    by nate nice ( 672391 ) on Thursday April 29, 2004 @05:46PM (#9012870) Journal
    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

    • Reminds me of a Chinese place a friend and mine use to eat at. The waitresses would always ask, "You wanna fork?" Naturally, it sounded like fuck instead of fork.
  • 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.

  • File handle passing (Score:3, Informative)

    by Nate Eldredge ( 133418 ) on Thursday April 29, 2004 @06:08PM (#9013132)
    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.)
    • Nonsense. It is impossible to pass a file handle from one process to another unless the 'other' process is a child. In which case you're not really passing it, anyway, are you. It is just continuing to exist along the path of execution.
      • Every hard-core UNIX programmer should know how to
        pass file handles between arbitrary processes.
      • From the unix socket man page:

        "Unix sockets support passing file descriptors or process credentials to other processes using ancillary data."
      • Okay, then, I'll put up. Please see this code [hmc.edu]. (I tried to post it here but the lameness filter prevented me.)

        Notice:

        • proc1 and proc2 are siblings, not parent and child
        • /tmp/foobar is never opened by proc2 or its parent
        • only proc2 writes the message "hello world"

        Yet somehow /tmp/foobar gets the message in it anyway.

        Credit Kragen Sitaker for the original code which I hacked to be a better demo. (I never claimed I could remember offhand how to do this, and I no longer have my copy of Stevens, but I

  • 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!
  • 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!

  • a true classic (Score:3, Interesting)

    by emmelaich ( 467112 ) on Thursday April 29, 2004 @06:33PM (#9013391)
    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)

    • (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)

      No way. Stevens wrote a UNIX book, not just the networking books. The UNIX book is about file IO, directory operations, system data files (passwd), process control and job control, signals, terminals, mmap, daemon writing, pipes, shared memory, message queues, FIFOs, semaphores, passing file descriptors, serial port IO, PTYs, etc.

    • If you're using Jtux in production, I love to hear more! Please email me privately.

  • 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.

    Allman style [dict.org]. (Yay! Was starting to think I was alone in the world.)

    Don't know what tcgetpgrp() does? The index will point you to 4.3.4.

    Big deal. /usr/bin/man will just tell me.

    termios(3):

    tcgetpgrp() returns process group ID of foreground processing group, or -1 on error.

    Sounds interesting enough, though, and everyone else seems to be

  • 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!)

  • Something wrong in the code? (Score:3, Funny)

    by Espectr0 ( 577637 ) on Thursday April 29, 2004 @07:19PM (#9013818) Journal
    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?
    • Every process has a unique process id (PID). The value is guaranteed to be unique for your process. The value in the example is not really relevant.
    • Straight from the man page

      NAME
      fork - create a child process

      SYNOPSIS
      #include
      #include

      pid_t fork(void);

      The 731 you get is the pid of the child process.
    • Am i doing something wrong?

      Yes. Before running the it the first way (stdout is the terminal), you need to wait until your system's process id counter is in the low 11100s -- check by using ps, top, or similar. That will ensure you get the "Returned 11111" output. (You might need to try it a few times.)

      Similarly before running it with the output directed to tmp, wait for the highest PID numbers returned by ps to get up to around 22218 before running it.

      Of course, if you don't care if your forked proc

  • 1st edition was great (Score:1, Insightful)

    by Anonymous Coward
    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!

  • Compared with Stevens? (Score:1, Insightful)

    by Anonymous Coward
    I have a copy of Advanced Programming in the Unix Environment [amazon.com], Unix Network Programming volume 1 [amazon.com] and volume 2 [amazon.com], and TCP/IP Illustrated, volume 1 [amazon.com].

    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 ...

    forktest@moo $ gcc moo.c
    /usr/lib/crt1.o: In function `_start':
    /usr/lib/crt1.o(.text+0x82): undefined reference to `main'
  • 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.
  • 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.
    • I wondered the same thing, when I found the bug while reviewing the code for the new edition. (You've just proved that my hope that nobody was paying attention was in vain. ;-)) This time, I took no chances: Since what that code was doing in 1984 is now handled by a library function, the whole section has been removed.

      Interestingly, this is the first comment I've gotten on the matter. I wasn't aware of it myself until about 18 months ago.

Slashdot Top Deals

The use of money is all the advantage there is to having money. -- B. Franklin

Close