whatever

Say that you want to run stuff written in Perl out of cron. Cron doesn't run as you. So it doesn't inherit your finely-crafted exported shell environment:

#setup the ENV that Perl knows about:
$ENV{ORACLE_HOME}='/opt/local/instantclient_10_2';
$ENV{LD_LIBRARY_PATH}='/opt/local/instantclient_10_2';

my $sqlplus;

$sqlplus=`sqlplus user/password\@DBNAME << END
sql statements here...;
exit
END
`;

open(MAILX, "| mailx -s 'db report' user\@domain ") || die "mailx no work
\n";
print MAILX $sqlplus;
close MAILX;


In addition, remember that to edit your crontab, you may need to: export EDITOR=vi

yeah yeah

just a reminder: when you're working in sqlplus:

> spool file.txt
> @script.sql
> spool off

now look inside 'file.txt' for the output of your query.

Perl modules different flavours

* the tried & trusted CPAN shell: perl -MCPAN -e shell ('install blah' etc)

* with Active Perl (no repos are maintained for Solaris/OSX etc) - so their 'ppm' command is no use there. ActiveState appear to have wrapped the CPAN shell into something that's invoked by : 'cpan'.

http://docs.activestate.com/activeperl/5.10/faq/ActivePerl-faq2.html#CPAN_shell

list installed perl modules

perl -MCPAN -e 'print CPAN::Shell->r '

oh yeah &:

"o conf init" inside of the MCPAN console to reconfigure (when the list of available mirror you picked proves to have been wildly over enthusiastic).

DBD::Oracle gotcha

when only the 'best' will do, ie. Oracle & Solaris: you have install the Perl DBD::Oracle module but whenever you try to load it (or run 'make test' etc) libnnz10.so is not found.

Go and check Oracle.so - this is the library created by the DBD::Oracle compile:

ldd -s Oracle.so | grep libnnz

This is one of the Oracle libs that was installed with instant client - in the location that should be your Oracle Home. You will see from the ldd output that it's expected to be found somewhere like /usr/lib. So even though you've defined $ORACLE_HOME & $LD_LIBRARY_PATH - that's not where the shared lib is looking for a dependency.

just make a symlink:

ln -s $ORACLE_HOME/libnnz10.so /usr/lib/libnnz10.so - or whatever the paths that will make it visible to the Oracle.so.

Oracle client-only on unix systems

I've seen DBAs grab & run the full Oracle installer on *nix systems just to get the client components. This is unecessary.

Go to the Oracle download site for the client components coresponding to the database verison you want to access. Install basic libs, sdk (probably optional) & sqlplus off the web.

* say you have installed all this in /opt/instantclient
then:
* set an ORACLE_HOME environment variable to /opt/instantclient
* add ORACLE_HOME to your PATH
* add ORACLE_HOME to your LD_LIBRARY_PATH
* set ORACLE_SID to the name of the database you usually want to connect to...

add a .tnsnames.ora file to your home dotfiles (I still do not know how to specify a default system-wide tnsnames file on unix).

Now, when you (or a script running in your environment) execute SQLPLus, it can find it's libraries etc. Likewise things such as DBD::Oracle will also work.

You CAN also dispense with a tnsnames file completely for SQLPLus - specifying host, port & datasource explicitly but this is a very long command line & requires escaping brackets etc.

EDIT (Jan 2010) - there are some systems where you will NEVER be able to get sqlplus to work - even if you follow the installation instructions. I suspect that there are just broken library paths compiled into the oracle binary. The attitude on the forums is the same as you will meet when dealing with most oracle admins: it's your fault, check everything that you've already checked etc. it's a problem with your OS, blah.

Such is the lot of the middleware guy. I'm just glad I won't have to do this shit for much longer...

Perl - read a bunch of files

# read in a directory trying to ignore non-image files

#!/usr/bin/perl

use Image::Magick;

my $image = Image::Magick->new;
$image->Set(bordercolor=>'#FFFFFF');

# args to the script:
my $argc = $#ARGV+1;

my @imageFilenames, my $target;
my @imageInfo;
my $inPath = $ARGV[0] . '/';
my $outPath = $ARGV[1] . '/';

opendir DIR, $inPath or die "cannot access $path\n";
@imageFilenames = grep{$_ ne '.' && $_ ne '..'} readdir DIR;
closedir DIR;

# process all the filenames
my $j = 0;
foreach $imageFilename (@imageFilenames) {
$target = join("", ($inPath, $imageFilename));
# test if the file returns width in pixels at least 1 - meaning that
# imagemagick can truly read it
@imageInfo=$image->ping($target);
if($imageInfo[1]<1) {
next; # ie. skip this iteration
}
status =" $image-">Read($target);
warn "error reading: $status\n" if $status;
print "reading $target\n";
}

undef $image;
exit;

maxim #1

don't tell me it's mission critical. Just tell me what you want me to do.

comment #1

...you're not deep, you're just an ass

cleaning up the filesystem

a mundane task - but why do I keep finding servers with disks almost full - because someone had a cron job - logging or saving out some data - but didn't put in anything to cleanup after themselves. The following will delete files from a destination after 14 days:

find /some/location/ -mtime +14 -exec rm {} \;

wasn't that hard was it?

The sensible thing is to test it non-destructively first by the way...so exec ls or something harmless for testing.