RR> initialize it at the top of each function to make sure it doesn't
 RR> contain a spurious value, or simple use the LOCAL thing on it.  My idea
 RR> here is to avoid the book-keeping nightmare imposed by PERL's demand
 RR> that the programmer keep track of global variable names in order to

 Hmm .. perhaps you missed the point.

 All variables spring into existence when used.  They are automatically
 global unless localized.  Local variables do not interfere with any
 global counterpart.  Generally, almost all variables are declared local
 at the start of a function, much like C.

 In fact, C auto variables are stack driven, and may contain anything
 in them (junk) - where PERL local variables, also stack based, contain
 whatever was in the global - so you don't get junk.

 RR> can be accessed within any function.  If the programmer wants to reuse
 RR> the identical name within his function as a local variable, he simply
 RR> defines it and uses it like any other automatic variable, without
 RR> worrying about the compiler forgetting which is which.  

 The compiler won't forget.  And you can use the names as you see fit.
 There is also a package keyword - used to scope variables and functions
 as being part of a package, or module.  You can reference the variables
 of another package using the package name and a ` character.

 RR> If you want more than one local variable with PERL, how do you do it
 RR> now?  Pick two global variables and LOCALize them?  Sounds a little
 RR> convoluted.  I would just use Temp1 and Temp2, etc.
 RR>  

 You don't have to pick globals - you just use whatever names you like.
 You may use multiple local() statements, or you may use an array assignment.

 Examples:

 sub func1 {
        local ($a,$b,$c,$d,$e);
 }
 
 # defined 5 local variables - unitialized

 sub func2 {
        local ($a,$b,$c,$d,$e) = @_;
 }

 # defined 5 local variables as the arguments to func2 - if you you supply
 # fewer than 5 arguments, the remaining are NULL or 0 initialized

 sub func3 {
        local ($a,$b,$c) = @_;
        local ($d,$e,$f) = (2,3,4);
        local ($_);
 }

 # defined $a through $c as local variables, arguments to func3 (as above)
 # defined $d through $e as local variables, $d = 2, $e = 3, $f = 4;
 # 'localized' the special variable $_ so that we can mangle it in func3
 # and not destroy its global value

 RR> variables be global unless temporarily declared otherwise.  I think it's 
 RR> much better to have all the variables within a function be automatic and 
 RR> local unless declared otherwise.
 RR>  

 It's just like BASIC or a bunch of other languages.  The local keyword isn't
 bad.  Besides, the language is for quick programs, not necessarily for
 designing the program of the decade.

EL>  The book is only $25 or so.  Get it :-)
 RR>  
 RR> I don't appear to have any need of PERL as I'm not extracting stuff out
 RR> of a database file at this time.  Before I spend any money on it I would 

 The code and docs with it are free.  As are many programs written in it
 on the Internet.  I once used PERL to find a bunch of FormFeed characters
 in a multi-megabyte print file and convert them to HP paper tray commands.
 The first page of each invoice in this print file needed a bottom tray 
 command instead of a form feed and each other page needed a top tray command.
 The file needed to be sent to an out-sourced printing company to be printed
 and mailed out and their systems were designed to key off those printer
 commands to extract and print the data - but someone messed with some
 options causing Form Feeds to be printed instead.  

 The PERL code was about 4 lines - try that with C !!  PERL integrates
 pattern matching and regular expressions - and search and replace was
 real easy - even though I was replacing one character with either one
 set of characters or another set based on what followed the form feed.
 Without PERL we wouldn't have gotten the file sent by noon, and would not
 have met our deadline on getting the customers their invoices on time.
 C would just take too long to write and debug something like that, and
 COBOL would have been impossible!! 

 PERL fills a gap between the shell script and the C application - its
 something very powerful to fill a need quickly - even if the resulting
 program is only used once, or used daily.

 Its not to replace C - it simply fills that middle ground. C++ is the
 above ground :-)  Its for writting HUGE applications and managing all
 your code and data.  All OOP really does is let you write larger programs
 and keep track of it all better - PERL 5 has objects too :-)

 

--- Maximus/2 3.00

[+/145 of 200/107 Mins] = * FIDO: ST_PROG =: Next...