Thursday, July 30, 2009

Running any process in background from perl script

If you want to run any process in background from your perl script as follows:

system("start [process]");

By using the above command, a new command window will get opened and the process will start running on that command window and control will return to your perl script from where you called this command, so the very next command can also be executed.

But if you use system("[process]"); then it will run on same command window and control will come back once the process is completed.

e.g.
system("start tail -f abc.txt");
print("Tail command is running in background\n");

will call a new command window and "tail -f " command will be executed in that and then print command will get called.

Tuesday, July 28, 2009

Perl Debugger Commands

C:\> perl -d xyz.pl

{Debugging Mode starts}
---> Type n to goto next line.
---> Type q to stop debugging .
---> b [x]: sets breakpoint @ x line
---> d [x]: to get rid of break point @ x line.
---> L : to examine breakpoints set in code
---> s : to step into any function @ any particular line.
---> Type h q for help on q command during debugging.
---> Type h R for help on R command during debugging( to restart the debugging )
---> Type h h for more help during debugging.

main::(book:3): my @books=( 'xyz', 'abc');
DB<1> n <--- command for "next" instruction main::(book:5): print @books;


DB<5> b 20
DB<6> L
DB<7> d 20

Perl Switches( CLO's)

>>perl -h for getting the help on command line options.
>>perl -v for getting the version of installed perl.

Usage
c:\>perl [switches] [Perl programfile] [Input arguments]
Switches to Perl Interpreter:-
Some important ones:
-w : Turn on many useful warnings( Use always, good for beginners)(RECOMMENDED)
-W : enable all warnings
-c : check syntax without actually executing the perl script.
-d : run script using perl debugger, to debug your script.

Some extra Switches:
-a : autosplit mode with -n or -p (splits $_ into @F)
-e : one line of program (several -e's allowed, omit programfile)
-E : like -e, but enables all optional features
-F/pattern/ : split() pattern for -a switch (//'s are optional)
-n : assume "while (<>) { ... }" loop around program
-p : assume loop like -n but print line also.
-P : run program through C preprocessor before compilation
-X : disable all warnings

Perl One Liners
>> perl -e [any perl instruction(statement) ]

*********************************************************************************
Examples:-
C:\> perl -e "print 'Hello World';" -e "print 'Howzit goin?';"
C:\> Hello WorldHowzit goin?

C:\> perl -n -e 's/^\s+//g; print $_;' file1
Above code is equivalent to

while(<>) {
s/^\s+//g;
print $_;
}


*************************************************
C:\>perl -p -e 's/\r//g' file1 > file1
above usage is a wrong way to write into file which is opened in reading mode, correct way will be as following:

C:\>perl -p -e 's/\r//g' file1 > file2
C:\>rename file2 file1
*************************************************
Note: Multiple -e statements can be used

Wednesday, July 22, 2009

Links for websites containing Perl related Info

The Perl CD BOOKSHELF (Ver 3.0)(O'Reilly) : (Latest Books)(Most of the O'Reilly Books for Perl are available for online reading)

The Perl CD BOOKSHELF (Ver 1.0)(O'Reilly) (Most of the O'Reilly Books for Perl are available for online reading)

Perl Doc Site (Perl Documentation Web Site)


Perl 5 Wiki ( Perl foundation Site)


Perl Online Books:(Single Book)
Perl For System Administration(1st edition)(O'Reilly) (Available in ver 2.0 of CD Bookshelf)

Fundamentals Of Perl( A online book)(Many Examples are given)


Perl Interview questions (Some Important questions which can be asked in interview)

Perl Training: (Some very good notes for Perl are available here)


Linux topia Picking Up Perl (Some information is available on Perl)

Perl Tutorials:
Perl Tutorial(Steve Cook) (Not for beginners)


PERL5 TUTORIAL( a pdf) (published in 2003)

PERL TUTORIAL POINT

Perl Tutorial(outdated): http://www.tizag.com/perlT/index.php


Perl Blogs:
Practical Perl blog (It's just a blog, so one may find some kind of information)
A Perl Blog



Difference between our and my in perl

How does 'our' differ from 'my' and what does 'our' do.

In Summary:

Available since Perl 5, 'my' is a way to declare:

* non-package variables, that are
* private,
* new,
* non-global variables,
* separate from any package; so that the variable
* cannot be accessed in the form of $package_name::variable.

On the other hand, 'our' variables are:

* package variables, and thus automatically
* global variables,
* definitely not private,
* nor are they necessarily new; and they
* can be accessed outside the package (or lexical scope) with the qualified namespace, as $package_name::variable.

Declaring a variable with 'our' allows you to predeclare variables in order to use them under "use strict" without getting typo warnings or compile-time errors. Since Perl 5.6, it has replaced the obsolete 'use vars', which was only file-scoped, and not lexically scoped as is 'our'.

For example, the formal, qualified name for variable $x inside package main is $main::x. Declaring 'our $x' allows you to use the bare $x variable without penalty (i.e., without a resulting error), in the scope of the declaration, when the script uses 'use strict' or 'use strict "vars"'. The scope might be one, or two, or more packages, or one small block.
===================================================================================



The PerlMonks and PerlDoc links from cartman and Olafur are a great reference - below is my crack at a summary:

my variables are lexically scoped within a single block defined by {} or within the same file if not in {}s. They are not accessible from packages/subroutines defined outside of the same lexical scope / block.

our variables are scoped within a package/file and accessible from any code that uses/requires that package/file - name conflicts are resolved between packages by prepending the appropriate namespace.

Just to round it out, local variables are "dynamically" scoped, differing from my variables in that they are also accessible from subroutines called within the same block.
==================================================================================
Coping with scooping(Namespaces)
is a document which has a good overview of Perl scoping rules, but it's old enough to have discussion about "our".
=================================================================================
perldoc is also a good reference.
=================================================================================
one can also refer to page for more reference.
=================================================================================
Perl has two kinds of variables. The first kind are global variables (also
called "package" variables or "symbol table" variables). These variables a)
have a name in a package's symbol table, and b) have a lifetime equal to the
duration of your process (Notwithstanding Perl's "local" statement, which
adds a twist. But save that for another discussion.)

You refer to a package variable like this:

$MyPackage::foo = 1;

This assigns to a scalar, $foo, in the "MyPackage" package. You don't have
to declare such a variable; it is created automatically simply by your
having used it's name.

Perl has a "package" statement, which allows you to define a default package
to be used when you don't explicitly specify one. So the following is
equivalent to what's above:

package MyPackage;
$foo = 1;

(If no package statement has been issued, the default package is "main").

But that raises a problem. Since global variables are created automatically,
it's easy to introduce bugs into your program by making typos in variable
names.

That's where "use strict" comes in. "use strict" (which should *always* be
used in your programs), requires you to pre-declare package variables that
you plan to use without a package name. Consider:

package MyPackage;
use strict;
$foo = 1; # compile-time error: $foo not defined

"our" is a declaration that introduces a package variable. So instead you
write:

package MyPackage;
use strict;
our $foo;
$foo = 1; # OK; $foo has been declared

You can combine the declaration and assignment in one step:

our $foo = 1;

Now if you accidentally misspell $foo as $fooo later in your program, Perl
will raise a compile-time error.

You can think of "our" as a license to use the variable without its package
name under "use strict".

"our" obeys lexical scoping rules. That is to say, your "license" is good
from the point you issue the "our", until the end of the innermost enclosing
block, eval, or file. Consider:

use strict;

{
our $foo;
$foo = 1; # OK, "our" declaration is in force
} # block ends, "our" declaration ends
$foo = 2; # compile-time error; outside of "our" scope

Note that "our" is never strictly required. "use strict" always allows you
to fully qualify a variable with a package name, even if you haven't
declared it with "our":

use strict;
$MyPackage::foo = 1; # legal anywhere

But doing this robs you of the compile-time checking that "use strict"
provides. So, we recommend the use of "use strict" and "our" for package
variables.

The second type of variable is a lexical variable. These are created with
the "my" statement. Unlike package variables, lexicals do not have an entry
in a package symbol table. lexical variables also have a lexical scope: they
have an existence only from the point of declaration until the end of the
innermost enclosing block. This makes them similar to "auto" or stack-based
variables in other languages. (Actually, the situation is more complex than
that; file-scoped lexicals have essentially global lifetime, and if a global
reference is taken to a block-scoped lexical, that value can persist beyond
the lexical scope, unlike in languages like C).

Anyway, you generally want to use the most restrictive scope appropriate for
your variables, in order to formalize the interfaces between your program's
parts and minimize the use of side effects through global variables. That is
why "my" variables are generally recommended over package variables.

There are some cases where you need package variables. For example, only
package variables can be exported through the Exporter.pm mechanism. Since
we always recommend the use of "use strict", you need to use "our" to
declare those variables. (However, note that *importing* a symbol via the
"use Package qw(list)" mechanism declares the symbols for the purposes of
"use strict". "our" only needs to be used in the module that exports the
symbols.)