doing

our @ISA = qw(Exporter);

our @EXPORT_OK = qw(
                        $cat
                        $cleartool
                        $chkconfig
                ) ;
[download]

Thanks Joost, now it works :-)

Bye,
Ron.

our %EXPORT_TAGS = ('DEFAULT'   =>[ qw( list of symbols ) ],
                    # Maybe other tags
                   );
    
Exporter::export_ok_tags(qw(DEFAULT any_others));
[download]

There are also many CPAN modules that do basic linux commands. Check out this node for some examples: Any perl modules for handling system operations

Also, when importing functions into a script, you will want to do something like the following:

use Benchmark qw( cmpthese );
[download]

Note the name of the function has no & which is generally used in front of a subroutine to show that it is a subroutine.

I would actually go a different way here. Instead of using variables, use functions. And don't return the string, accept the arguments. This would allow you to do things such as swap out implementations later. So, instead of:

  system($cp, $from, $to);
[download]

  cp($from, $to);
[download]

sub cp {
  system('/bin/cp', @_);
}
[download]

sub cp {
  require File::Copy;
  File::Copy::cp(@_);  #doesn't work for wildcards, I think.
  # File::Copy::cp(map {glob $_}, @_) # <-- might be needed for wildca
+rds
}
[download]

Reasons for this approach:

• Speed. Oftentimes, doing stuff in perl is just as fast as doing it in C. For example, copying files is more limited by disk/network speed than CPU speed, so perl will be just as fast for the copying part. But doing it in pure perl means you don't have the overhead of a fork and exec. Or more than one fork and exec if you use the shell in between. I have one perl program that literally copies dozens of GB, over 100,000 files, and this switch did affect the time it takes to perform the copies.
• Portability. You don't need to worry about different OS's and their different calling mechanisms. e.g., cp on unix/linux vs copy on windows. File::Copy will do it right on all of them. The above program I work on works on Windows (ia32, x64, ia64), AIX, Sun (SPARC, x64), HP (PA-RISC, ia64 aka IPF), and Linux (ia32, x64, ia64, ppc64, s390x). We've added multiple platforms over the last few years with basically no tweaking. We only call out to the shell when we have no other choice in perl.
• Portability. Yes, again. Different distros of Linux often do things different. While cleartool probably isn't going to move (since it's not owned by any distro), cp might. So when you move from RH to SuSE to Debian to Gentoo - or vice versa - something may have changed. By reducing your dependency on the hardcoded locations of applications, you reduce your exposure to those changes.
• It's just cool. ;-) You own your own work. And, with that, comes the flexibility to do things the way you need to. Need to handle regexp's in your copy command instead of globs? No problem! Cleartool acting funny when passed in multiple files? Just a tweak to the sub, and that can be dealt with as well (by calling it repeatedly)! You centralise your interface, making it possible to fix an external problem in a single internal location, rather than dealing with it all over your code.

package LinuxCommandsPaths;

use strict;
use vars qw(
         @ISA @EXPORT_OK
         $cat
         $cleartool
         $chkconfig
         );
require Exporter;
@ISA = qw(Exporter);

@EXPORT_OK = qw(
                        $cat
                        $cleartool
                        $chkconfig
                ) ;

our $cat = '/bin/cat';
our $cleartool = '/usr/atria/bin/cleartool';
our $chkconfig = '/sbin/chkconfig';

1;
[download]

#!/usr/bin/perl -iw
#
use strict;
use vars qw(
    $cat $cleartool $chkconfig
    );
use LinuxCommandsPaths qw($cat $cleartool $chkconfig);

print "\$cat == |$cat|\n";
print "\$cleartool == |$cleartool|\n";
print "\$chkconfig == |$chkconfig|\n";
[download]

Thanks SFlex, for the code. Great help.

Bye,
Ron.