On 9 November 2010 15:44, Tom Christiansen <tchr...@perl.com> wrote:
> 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?
Personally I really wish you had kept the changes to use lexically
scoped filehandles.
cheers,
Yves
--
perl -Mre=debug -e "/just|another|perl|hacker/"
