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

Reply via email to