Re: [PATCH mg.c gv.c and others] ${^TAINT}
[p5sagit/p5-mst-13.2.git] / pod / perlfaq3.pod
index 4eceb46..efa764d 100644 (file)
@@ -1,6 +1,6 @@
 =head1 NAME
 
-perlfaq3 - Programming Tools ($Revision: 1.38 $, $Date: 1999/05/23 16:08:30 $)
+perlfaq3 - Programming Tools ($Revision: 1.4 $, $Date: 2001/10/02 19:42:02 $)
 
 =head1 DESCRIPTION
 
@@ -41,10 +41,22 @@ operations typically found in symbolic debuggers.
 
 =head2 Is there a Perl shell?
 
-In general, no.  The Shell.pm module (distributed with Perl) makes
-Perl try commands which aren't part of the Perl language as shell
-commands.  perlsh from the source distribution is simplistic and
-uninteresting, but may still be what you want.
+In general, not yet.  There is psh available at
+
+    http://www.focusresearch.com/gregor/psh
+
+Which includes the following description:
+
+    The Perl Shell is a shell that combines the interactive nature
+    of a Unix shell with the power of Perl. The goal is to eventually
+    have a full featured shell that behaves as expected for normal
+    shell activity. But, the Perl Shell will use Perl syntax and
+    functionality for for control-flow statements and other things.
+
+The Shell.pm module (distributed with Perl) makes Perl try commands
+which aren't part of the Perl language as shell commands.  perlsh
+from the source distribution is simplistic and uninteresting, but
+may still be what you want.
 
 =head2 How do I debug my Perl programs?
 
@@ -118,27 +130,28 @@ to generate cross-reference reports for Perl programs.
 
 =head2 Is there a pretty-printer (formatter) for Perl?
 
-There is no program that will reformat Perl as much as indent(1) does
-for C.  The complex feedback between the scanner and the parser (this
-feedback is what confuses the vgrind and emacs programs) makes it
-challenging at best to write a stand-alone Perl parser.
-
-Of course, if you simply follow the guidelines in L<perlstyle>, you
-shouldn't need to reformat.  The habit of formatting your code as you
-write it will help prevent bugs.  Your editor can and should help you
-with this.  The perl-mode or newer cperl-mode for emacs can provide
-remarkable amounts of help with most (but not all) code, and even less
-programmable editors can provide significant assistance.  Tom swears
-by the following settings in vi and its clones:
+Perltidy is a Perl script which indents and reformats Perl scripts
+to make them easier to read by trying to follow the rules of the
+L<perlstyle>. If you write Perl scripts, or spend much time reading
+them, you will probably find it useful.  It is available at
+http://perltidy.sourceforge.net
+
+Of course, if you simply follow the guidelines in L<perlstyle>,
+you shouldn't need to reformat.  The habit of formatting your code
+as you write it will help prevent bugs.  Your editor can and should
+help you with this.  The perl-mode or newer cperl-mode for emacs
+can provide remarkable amounts of help with most (but not all)
+code, and even less programmable editors can provide significant
+assistance.  Tom Christiansen and many other VI users  swear by
+the following settings in vi and its clones:
 
     set ai sw=4
     map! ^O {^M}^[O^T
 
-Now put that in your F<.exrc> file (replacing the caret characters
+Put that in your F<.exrc> file (replacing the caret characters
 with control characters) and away you go.  In insert mode, ^T is
 for indenting, ^D is for undenting, and ^O is for blockdenting--
-as it were.  If you haven't used the last one, you're missing
-a lot.  A more complete example, with comments, can be found at
+as it were.  A more complete example, with comments, can be found at
 http://www.perl.com/CPAN-local/authors/id/TOMC/scripts/toms.exrc.gz
 
 If you are used to using the I<vgrind> program for printing out nice code
@@ -474,6 +487,56 @@ Information about malloc is in the F<INSTALL> file in the source
 distribution.  You can find out whether you are using perl's malloc by
 typing C<perl -V:usemymalloc>.
 
+Of course, the best way to save memory is to not do anything to waste
+it in the first place. Good programming practices can go a long way
+toward this:
+
+=over 4
+
+=item * Don't slurp!
+
+Don't read an entire file into memory if you can process it line
+by line. Or more concretely, use a loop like this:
+
+       #
+       # Good Idea
+       #
+       while (<FILE>) {
+          # ...
+       }
+
+instead of this:
+
+       #
+       # Bad Idea
+       #
+       @data = <FILE>;
+       foreach (@data) {
+           # ...
+       }
+
+When the files you're processing are small, it doesn't much matter which
+way you do it, but it makes a huge difference when they start getting
+larger. 
+
+=item * Pass by reference
+
+Pass arrays and hashes by reference, not by value. For one thing, it's
+the only way to pass multiple lists or hashes (or both) in a single
+call/return. It also avoids creating a copy of all the contents. This
+requires some judgment, however, because any changes will be propagated
+back to the original data. If you really want to mangle (er, modify) a
+copy, you'll have to sacrifice the memory needed to make one.
+
+=item * Tie large variables to disk.
+
+For "big" data stores (i.e. ones that exceed available memory) consider
+using one of the DB modules to store it on disk instead of in RAM. This
+will incur a penalty in access time, but that's probably better that
+causing your hard disk to thrash due to massive swapping.
+
+=back
+
 =head2 Is it unsafe to return a pointer to local data?
 
 No, Perl's garbage collection system takes care of this.