On 09 Nov 2010 06:02:55 GMT you wrote: >> For now, I'm sending the complete revision in toto.
> Applied as cf21866, with some tpyo corretcions. Thanks very muhc. I think it's a better document now, even if only marginally. ======= TYPOS ======= Even though my last step was to spell-check it, a few typos still made it through. Here are four that I'm aware of: 1. Be careful qx(), system(), and some modules for calling external commands ^ ^ insert ":" right after "careful" 2. exit if $pid; # non-zero now mean I am the paren ^ ^ change "mean" to means" 3. resort to the harder-to-readm, multi-argument form of pipe open(). However, ^ ^ delete that "m" 4. Chapter 6 of the Camel. ^ ^ That should now be "16", not "6". ======== POLICY ======== That last one snuck past me because I always quickly avert my eyes from such self-mentions. I'm *terribly* queasy about the least hint of what could be perceived as pecunious self-promotion. I justify it in this case solely because it might also help out Larry, who otherwise receives so very little for his lifetime of work on Perl; it's the least we can do. Yet I'm bothered because it seems somewhat unfair to readers to point them only at Camel:16 when Cookbook:14-18 covers that material in much richer detail. But I cannot do that, given that I can no longer justify it in the same way: Larry has only an intro in PCB, which had its notional origin in material I split off from v1 Camel when making v2. Even perlipc itself I wrote as dry-run for Camel v3, just like many other standard pods. Not providing better references seems unfair to other authors (not me) whose own works might quite reasonably be referenced here and elsewhere in the standard Perl documentation, but that is a huge can of worms that we long ago decided not to open, as evinced by perlbook(1). So I feel it must be left as is--or rather, as amended to "16"--without the Cookbook reference, even though this really is too bad, especially when the full source code is downloadable for free. The current policy should stand. I don't want to open that up. It's just not worth the bother, or the risk. Oh well. ============ CODE FIXES ============ Beyond unifying the code back into my own style where it had become internally inconsistent and generally tightening it up in many places, I also improved the code's error checking, naming of identifier, and comments. In places I reduced code complexity by factoring out some of the deeply nested indentation. I provided an additional multi-arg pipe example to better explain the problem of shell metachars, the guts of which is: @grep_args = ("egrep", "-i", $some_pattern, @many_files); =============== ENGLISH FIXES =============== Besides trivial changes like normalizing spelling and to a lesser extent fonting, I smoothed out the phasing in quite a few places, including inlining some of the many parenthetical statements (which can be pretty distracting otherwise (don't you think?)). I reduced the number of explicit mentions of Unix where this made sense to do. I amended statements about the Mac so that it was clear that these applied only to pre-Darwin releases. I mentioned IPC::Shareable and threads::shared where appropriate. I excised mention of Comm.pl, as it is likely older than many of the readers, and far less healthy. One of my TODOs I left intact: =for TODO Hold on, is this even true? First it says that socketpair() is avoided for portability, but then it says it probably won't work except on Unixy systems anyway. Which one of those is true? That follows these two sentences: Although it might have been more efficient by using socketpair(), this would have been even less portable than it already is. The open2() and open3() functions are unlikely to work anywhere except on a Unix system, or at least one purporting POSIX compliance. Are *both* those two statements really still needed? I've been led to believe that open2/3 do work on Microsoft systems, but that they do so there for reasons other than MS's not-useful letter-of-the-law POSIX compliance. Do they work on VMS? What non-Unix systems apart from Microsoft and VMS do people still use? What about iOS? thanks again, --tom