Robert Spier <[EMAIL PROTECTED]> writes:
> I remember a similar patch once before that did the expand/interpolate
> thing.
Not just similar. The same - give or take a few refinements.
> There was some reason people didn't like it.
You can go back to the archives to see for yourself if you like, but
it was largely a personality thing. I didn't proof read it well
enough before submitting it the last time and there were some typos.
You understandably were irritated by this and refused therefore to
consider the patch even after I'd fixed the typos and cleaned up
sources of potential confusion that were pointed out to me.
I hope enough time has gone by that you can put your feelings to one
side and consider this purely on its merits. It may not be perfect.
But it is better than what's there now - and surely that should be the
prime concern.
> > +See also ``How can I expand/interpolate variables in text strings?''
> > +in this section of the FAQ.
> > +=head2 How can I expand/interpolate variables in text strings?
> >
> > -Let's assume that you have a string like:
> > +To process a string through Perl's interpolation engine simply:
> >
> > - $text = 'this has a $foo in it and a $bar';
> > + $text = 'this has a $foo in it...\n ...and a $bar';
> > + # Assume $text does not contain "\nEND\n"
> > + chop ( $text = eval "<<END\n$text\nEND\n" );
> > + die if $@;
>
> I don't think we want to show eval in this context in the FAQ. It
> will confused beginners to no end.
But the eval solution _is_ the answer to the question that people who
ask this question are asking. If there really is a concensus is that
the true answer to the question is too confusing for the FAQ then
surely we should remove the question from the FAQ altogether. Leaving
the question but answering only a particular special case of the
question can only be more confusing in the long run.
At the moment we have the perverse situation where people _are_
genuinely frequently asking this question in the Usenet groups but we
can't simply point them to the FAQ because the answer given in the FAQ
is not the answer to the question. Worse still when someone does post
an RTFFAQ response we actually have to correct them! Our efforts to
persuade people not to post questions that are answered in the FAQ are
being undermined.
> > +This will not work, for good reason, if $text is tainted. For an
> > +explanation of how $text could execute arbitrary Perl see ``How do I
> > +expand function calls in a string?'' in this section of the FAQ.
>
> What is tainting? (I know. I'm being rhetorical.) That seems outside
> the scope of the question.
People are reluctant to have the FAQ give the true answer to the
question without making some reference to the dangers. I wanted to
alert people to the dangers in as few words as possible. For the most
part I do this by referring readers to perlsec. I mention tainting to
set the scene for the referrence to perlsec.
> > - $text =~ s/\$(\w+)/${$1}/g; # no /e needed
> > +If $text comes from a source external to the Perl script (typically a
> > +file) and you trust executable code from that source then simply
> > +untaint it. This is no more or less dangerous than using C<do()>.
> > +For an explaination of tainting see L<perlsec>.
>
> Definitely outside the scope.
So are you suggesting we just answer the question and don't discuss
the dangers?
The trouble is that many highly respected people are unhappy with the
FAQ giving the true answer to the question without dicussing the
dangers - indeed over the years this has been cited as the reason the
FAQ does not currently actually contain the true answer to the
question at all.
Or are you suggesting that, as now, the FAQ should withold the true
answer to the question because there are dangers?
The trouble with that is it means that people either discover the true
answer for themselves or obtain it from some other source. Experience
has shown that they may get an inferrior answer (without the here-doc
trick) and may not be made aware of the dangers. It also, of course,
devalues the FAQ in their eyes when they discover that it didn't give
the simple and accurate answer to their question.
> > -But since they are probably lexicals, or at least, they could
> > -be, you'd have to do this:
> > +If you do not trust the source, you can limit and launder the parts of
> > +$text that are passed to eval():
> >
> > - $text =~ s/(\$\w+)/$1/eeg;
> > - die if $@; # needed /ee, not /e
> > + $text =~ s/(\$\w+)/$1/eeg; # needed /ee, not /e
>
> I'm not sure why you removed the error checking. Sure, it doesn't
> necessarily fit either, but it is better to explain it than eliminate
> it.
I'm not sure either. I guess I figured that since I'd mentioned it
above it didn't need to be repeated. Put, it back in by all means.
Any explaination would, however be outside the scope.
> > -See also ``How do I expand function calls in a string?'' in this section
> > -of the FAQ.
> > +For other variations on the theme of text templates see the sprintf()
> > +function and numerous modules on CPAN.
>
> Huh?
>
> That's removing information.
No it is not. It is removing noise.
The reference to the other FAQ was moved further up where it now makes
some sense.
Go back and read the current version of the FAQ. In it's original
location this reference to the other question made no sense. The two
questions (particularly with the orginal answer that didn't mention
eval()) are, if fact, quite unrelated despite a superficial similarity
in their wording.
I think you are making the mistake of reading the patch as a patch. I
warned against this. The new answer should be viewed in its entirity
and contrasted with the old answer. Focusing on the line-by-line
insertion/deletion artifacts produced in the 'diff -u' output clouds
the issue.
