Re^3: possible perl5.8.7 bug?

You seem to rely on perl5.8.7 to be found via $ENV{PATH} - I would want to eliminate any such reliance by using an explicit exec /opt/perl/bin/perl5.8.7, so that both users will always invoke exactly the same Perl binary. As BerkeleyDB uses a binary component, that component must be tailored to the perl5.8.7 you use. If for example one Perl was compiled with threads and the other wasn't, that might lead to the problems.

Also, could you elaborate on how the runme.sh "fails" ? Is there any error output given?

Comment on Re^3: possible perl5.8.7 bug? Select or Download Code

Replies are listed 'Best First'.
Re^4: possible perl5.8.7 bug? by Pstack (Scribe) on Jan 04, 2006 at 04:18 UTC
Unfortunately runme.sh has to have this form for cron: exec perl5.8.7 cronmgr.pl < /dev/null >&0 2>&0 and, of course, I cannot even pass back a useful exit value from cronmgr.pl because it is always seen as null (as long as the 5.8.7 interpreter itself fires ok, which it does!). And leaving out the chaining effect of exec, other subsequent commands in runme.sh will execute ok too. But food for thought on the config issues after a cron upgrade, if that doesn't help. cheers Pstack	[reply]
Re^4: possible perl5.8.7 bug? by Pstack (Scribe) on Jan 11, 2006 at 06:59 UTC
My apologies. I did reply, but it may have been pulled due to non-formatting or poor-formatting! Cheers. Pstack	[reply]