Running some script via cron on Solaris gives me a totally different @INC compared to running it manually (root in both cases). The problem that is caused by different @INCs is that I can't use any use statement, even something like use strict.

I know that the Solaris 5.8 machines I tried to run the script on have some (identical) awkward Perl configuration, though running the script manually works fine ... Meddling with the @INC (both use lib and BEGIN {unshift(@INC,'/any/path');}) causes the script to fail - again, only when it's being run via cron.

On one hand I could probably rewrite my custom modules to make .pl files out of them and simply remove use strict/warnings, but it just beats the purpose of modules and simply goes against my nature. On the other hand we're talking work here and I can't really spend years on making a script of several hundreds lines work (for now I've spent about 15 hours in the office today).

Spending major part of a day on debugging the script that took less than 2 hours to write is very discouraging (specially taking into account the fact that it really shines when run manually or inside while 1), but it's now a matter of principle - me against the cron . Please help me not to loose to the soulless software

A first guess would be that the two invocations are using different Perl installations. Try running "which perl" from both the command line and from a cron job.

Another alternative is that when you are running from the command line then you have a PERL5LIB or PERLLIB setting which alters the value of @INC. Try running "perl -V" from both the command line and from a cron job.

Finally figured it out - the weird installation I wrote about assumed you sourced a .tcshrc equivalent, so wrapping the perl script in a .tcsh that runs the source before running the script itself works as a charm.