in reply to Trouble finding modules from cron

Knowing this will probably happen again i would make a script called /usr/bin/perlcron

#!/bin/sh perl -I /some/special/libpath:/another/special/libpath "$@"
and chmod ugo+x it. Then when you enter your command to be run by cron just preface it with /usr/bin/perlcron. ie "/usr/bin/perlcron myscript". This has the advantage that you can also do things like setup a special path when your path is not the path that cron uses. That way you dont need to add any special code to your scripts, it is taken care of in perlcron. And the next time you want to run a perl script by cron you are all set to go,, just use perlcron again to start it

Replies are listed 'Best First'.
Re^2: Trouble finding modules from cron
by Your Mother (Archbishop) on Apr 11, 2017 at 18:07 UTC

    Nice. I feel silly for how many scripts Iíve edited around this problem when there was such a simple and obvious way around it. Next time I need to update something, Iíll try this approach.

Re^2: Trouble finding modules from cron
by afoken (Chancellor) on Apr 13, 2017 at 04:30 UTC
    #!/bin/sh perl -I /some/special/libpath:/another/special/libpath "$@"

    Drop in an exec to get rid of a needless /bin/sh instance:

    #!/bin/sh exec perl -I /some/special/libpath:/another/special/libpath "$@"

    And if you have more than one perl, specify which one you want to start. Also do this if you are not sure what $ENV{'PATH'} may contain.

    #!/bin/sh exec /usr/local/perl-5.42.99/bin/perl -I /some/special/libpath:/anothe +r/special/libpath "$@"

    But then again, cbeckley++ is right, perl can do fine without a shell:

    #!/usr/local/perl-5.42.99/bin/perl use lib '/some/special/libpath','/another/special/libpath'; # rest of the script here, unmodified

    Perl does not even mind if you prefix those two lines to an existing script, the shebang (#!) line of the existing script will be parsed as a comment.

    If you don't want to modify scripts, you can also use a perl script as a wrapper:

    #!/usr/local/perl-5.42.99/bin/perl use lib '/some/special/libpath','/another/special/libpath'; require '/path/to/real/';


    This simple one assumes that returns a true value. Alternatively, use do $filename, but that needs more code for error handling:

    #!/usr/local/perl-5.42.99/bin/perl use lib '/some/special/libpath','/another/special/libpath'; unless (defined(do '/path/to/real/')) { die "Could not parse script: $@" if $@; die "Could not read script: $!"; }


    Generally, if you run a script as root or setuid root, consider adding -T to the shebang line to enable taint mode (see perlsec).


    Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so". ;-)
Re^2: Trouble finding modules from cron
by faineant (Beadle) on Apr 12, 2017 at 19:11 UTC

    I've tried your suggestion and the one provided by cbeckley.

    Both work, but are there reasons for choosing one approach over the other?

    Thanks -F

      In the "-I" approach the biggest consideration comes from module movement. If the modules move from /some/location to /another/location only one place (/usr/bin/perlcron) needs to change and all the programs using those modules are repaired. When using findbin/lib each program itself has to be repaired. At one site i was at we moved boxes 4 times in about 7 years, each move with changes to the names of the file system paths. In that case it wasnt for cron, but to ensure a working production environment. As soon as i fixed the initiator-script all the processes worked under the new locations. I also use this method still on my home boxes, various windoz and linuxen, each with its own customized initiator script to let it run in that environment.

        I would only add that if the scripts and the modules are going to maintain their relative positions in the file system before and after a move, then no change is required with

        use lib "$FindBin::Bin/../path/to/modules";

        However if there's a risk that the modules might move in relation to the scripts, then huck's solution is certainly more flexible.