summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorFather Chrysostomos <sprout@cpan.org>2012-06-18 20:43:03 -0700
committerFather Chrysostomos <sprout@cpan.org>2012-06-18 20:43:03 -0700
commite8c6d8abf88b67e51ceb0dd1a8ca94f3a23874c4 (patch)
treec1b1f3671dcb56666a8768d632a555b03dd84a76
parent33c6567b4b9cfe8fe9757d33c3278db5e95b8a7e (diff)
downloadperl-e8c6d8abf88b67e51ceb0dd1a8ca94f3a23874c4.tar.gz
Revert perlfilter part of 318b791f053
The CPAN release has an old version.
-rw-r--r--pod/perlfilter.pod14
1 files changed, 7 insertions, 7 deletions
diff --git a/pod/perlfilter.pod b/pod/perlfilter.pod
index f96fe6691a..27061883c1 100644
--- a/pod/perlfilter.pod
+++ b/pod/perlfilter.pod
@@ -204,7 +204,7 @@ source filter (see Decryption Filters, below).
All decryption filters work on the principle of "security through
obscurity." Regardless of how well you write a decryption filter and
-how strong your encryption algorithm, anyone determined enough can
+how strong your encryption algorithm is, anyone determined enough can
retrieve the original source code. The reason is quite simple - once
the decryption filter has decrypted the source back to its original
form, fragments of it will be stored in the computer's memory as Perl
@@ -217,7 +217,7 @@ difficult for the potential cracker. The most important: Write your
decryption filter in C and statically link the decryption module into
the Perl binary. For further tips to make life difficult for the
potential cracker, see the file I<decrypt.pm> in the source filters
-module.
+distribution.
=back
@@ -226,7 +226,7 @@ module.
An alternative to writing the filter in C is to create a separate
executable in the language of your choice. The separate executable
reads from standard input, does whatever processing is necessary, and
-writes the filtered data to standard output. C<Filter:cpp> is an
+writes the filtered data to standard output. C<Filter::cpp> is an
example of a source filter implemented as a separate executable - the
executable is the C preprocessor bundled with your C compiler.
@@ -234,7 +234,7 @@ The source filter distribution includes two modules that simplify this
task: C<Filter::exec> and C<Filter::sh>. Both allow you to run any
external executable. Both use a coprocess to control the flow of data
into and out of the external executable. (For details on coprocesses,
-see Stephens, W.R. "Advanced Programming in the UNIX Environment."
+see Stephens, W.R., "Advanced Programming in the UNIX Environment."
Addison-Wesley, ISBN 0-210-56317-7, pages 441-445.) The difference
between them is that C<Filter::exec> spawns the external command
directly, while C<Filter::sh> spawns a shell to execute the external
@@ -388,9 +388,9 @@ Two special marker lines will bracket debugging code, like this:
}
## DEBUG_END
-When the C<DEBUG> environment variable exists, the filter ensures that
-Perl parses only the code between the C<DEBUG_BEGIN> and C<DEBUG_END>
-markers. That means that when C<DEBUG> does exist, the code above
+The filter ensures that Perl parses the code between the <DEBUG_BEGIN>
+and C<DEBUG_END> markers only when the C<DEBUG> environment variable
+exists. That means that when C<DEBUG> does exist, the code above
should be passed through the filter unchanged. The marker lines can
also be passed through as-is, because the Perl parser will see them as
comment lines. When C<DEBUG> isn't set, we need a way to disable the