The problem is that in the BEGIN block your script chdirs to a different directory from where you invoked the script, so, by the time that pod2usage is executed, the value returned by $0 (which pod2usage relies on) no longer points to the script. This is an easy problem to fix, but I don't understand why your script is chdir-ing in the first place.

Well, I've changed by BEGIN block as follows:

BEGIN {
    use strict;
    use warnings;
    print "I am here!\n";
    use Pod::Usage qw( pod2usage );
    ### Bomb if there is nothing on the command line ###
    pod2usage(2) if ( not @ARGV );
    print "I am there!\n";
    @cmd = fileparse( File::Spec->rel2abs( $0 ), '\.[^.]*' );
    $LIBPATH = File::Spec->catdir( $cmd[1], "../lib" );
    eval " use lib '$LIBPATH'";
    chdir "$LIBPATH";
    
    use Data::Dumper;
    printf "---ENV---\n%s\n", Dumper( \%ENV );
    
}
[download]

Now here's the funky part, on a Win32 box, I get the output:


I am here!
Usage:
    move_data.pl [options]

    Options:

     -help..........Brief help message
     -man...........Full documentation
     -config........Full path to the configuration file
[download]

Which is what I expected, while on a Linux machine, I only get the I am here!...
What gives?

Which is what I expected, while on a Linux machine, I only get the I am here!...

Odd, works just fine for me. Maybe you should try running it in the debugger. Since the relevant code is in a BEGIN block, you need to put

        BEGIN {
            $DB::single = 1;
            ...
[download]

in there to make sure the debugger doesn't just jump over it. Then, call

    $ perl -d move_data.pl
[download]

from the command line and step through the source lines using n and s.

That's what I thought. Currently the script is set to: -rwxr-xr-x
Should I open up the w as well?

Apparently not, since the error is about reading:

Can't open ./move_data.pl for reading: No such file or directory at ./move_data.pl line 18




---
Er Galvão Abbott
www.galvao.eti.br
Porto Alegre Perl Mongers

As others have pointed out, your problem seems to stem from the chdir command. Your solution involved placing yet more stuff into the BEGIN block where the chdir is.

My question is - why use a BEGIN block here in the first place? A BEGIN block is used when you want something to happen at compile time. In your case, you have "use" statements that take place anyway at compile time - so why place them in a BEGIN block? You also run a few other commands that may or may not benefit from being run at compile time - I can't tell. But from what I see, you would gain more clarity if you moved everything in the BEGIN block to the body of the program.

Just my 2 cents worth...

The Big Reason(TM) for the BEGIN block is to allow for use'ing the MoveDataTools package in a dynamic way.
For example, we don't really know where the user installed this script, but we do know where the libs were installed in relation to the script. The BEGIN block is there to help figure out the correct LIB path, based on the script's path.
I am also trying to keep this seperate from the local perl install to avoid poluting it with extra stuff, that we don't really want to give global access to.
This whole thing is really weird because it works fine on the Windows box I built this on, and except for the pod2usage call works fine on a linux machine as well.
Bummer!
In any case, thank you all for your input on this!

The BEGIN block is there to help figure out the correct LIB path, based on the script's path.

The FindBin module might here you there. Check out the synopsys examples.

Regarding the Pod::Usage problem, what happens if you move the "use Pod::Usage" line outside (before) the BEGIN block? Does that help?

HTH :-)

#!/usr/bin/perl -w
# 
# $Id: move_data.pl,v 1.12 2005/05/05 21:25:58 dwhitney Exp $

### Declaire script vars ###
use vars qw( $Executable $Transaction @cmd $LIBPATH );
$|++;    # Turn on autoflush

### Import pre-requisite packages
use strict;
use warnings;
use Log::Log4perl;
use Getopt::Long qw( GetOptions );
use Cwd qw( chdir realpath );
use Benchmark qw( timestr timediff );
use File::Basename qw( fileparse );
use File::Spec qw( catfile rel2abs );
use Pod::Usage qw( pod2usage );
### Bomb if there is nothing on the command line ###
pod2usage(2) if ( not @ARGV );

BEGIN {
    $LIBPATH = "../lib";
    @cmd = fileparse( File::Spec->rel2abs( $0 ), '\.[^.]*' );
    $LIBPATH = File::Spec->catdir( $cmd[1], "$LIBPATH" );
    eval " use lib '$LIBPATH'";
}

### Use the MoveDataTools package ###
use MoveDataTools;
[download]

Hello all, Same problem, resolved by converting the script file to unix end-of-line with dos2unix.

Ah, yes. This has given me problems before, often with Unix-style programs operating on DOS-style data. Good to remember to check for these sorts of issues.

In the quest for a utility to convert between *nix and DOS newlines on a regular basis, I have found flip: Newline conversion between Unix, Macintosh and MS-DOS ASCII files to be useful. It not only converts between DOS and Unix file formats, but also includes a handy -t command-line switch to tell you which format a given file uses.

HTH,

planetscape