weigand has asked for the wisdom of the Perl Monks concerning the following question:

I have several different machine architectures and OS (linux 2.4, linux 2.6, solaris, etc.). For each of those, I have several different builds of perl (with threads, without threads, with specific versions of modules, etc.).

I want to have a shell script which will act as a wrapper to choose the right perl version. I know how to figure out the OS and architecture automatically using uname and such. And I will pass special command line arguments to it in order to tell it that I want the threaded perl version or the non-threaded one. Etc.

But I'm getting into trouble.

Let's say the wrapper shell script is at "/usr/local/bin/perl_wrapper". I would really like to do something like this in my perl script:

#! /usr/local/bin/perl_wrapper print "Hello World!\n";

But that doesn't seem to work, because apparently "#!" needs to be followed by a compiled binary, not a shell script?

Okay, I can accept that. So I tried using "env" instead:

#! /usr/bin/env /usr/local/bin/perl_wrapper print "Hello World!\n";

Hey, that works! Great. Now let me just add that "-w" perl switch to it....

#! /usr/bin/env /usr/local/bin/perl_wrapper -w print "Hello World!\n";

Uh-oh! I get this error message:

/usr/bin/env: /usr/local/bin/perl_wrapper -w: No such file or direct +ory

It's like it's trying to find a file called "/usr/local/bin/perl_wrapper -w".

Okay, what do I do now? You can't pass command line arguments when you use /usr/bin/env?

Any help would be appreciated.

Thanks!

--- UPDATE: For some reason, my carriage return characters aren't showing up in the text above? Oy.

--- UPDATE 2: Okay, now it should be formatted better.

Replies are listed 'Best First'.
Re: Perl wrapper
by ikegami (Patriarch) on Mar 15, 2011 at 23:12 UTC

    Seem to me it's simpler if you avoid the recursion altogether.

    script:

    #!/bin/sh wrapper real_script "$@"

    wrapper:

    #!/bin/sh perl "$@"

    real_script:

    #!perl -w 4; print("Hello, World\n");
    $ script Useless use of a constant (4) in void context at real_script line 2. Hello, World
Re: Perl wrapper
by ikegami (Patriarch) on Mar 15, 2011 at 23:27 UTC

    And now without the extra file.

    wrapper:

    #!/bin/sh perl "$@"

    script:

    #!/bin/sh #!perl -w eval 'exec wrapper -x -S $0 ${1+"$@"}' if 0; 4; print("Hello, World\n");
    $ script Useless use of a constant (4) in void context at script line 5. Hello, World

    See perlrun.

      Thanks for the reply. That definitely solves the problem.

      I just wish there was an easier way. I basically have to tell everyone at my company that they need to cut and paste this little piece of code at the top of their perl scripts. The "/bin/sh" at the top may be a bit confusing to them also.

      Still, it's better than the alternative: Having to write a shell script every time you want to run a perl script (two files instead of one).

      I wish /bin/env would just allow me to pass command line arguments to perl. Why can't it? And is there something like /bin/env that would?

        just wish there was an easier way.

        We're constrained by your requirement to call the wrapper.

        I basically have to tell everyone at my company that they need to cut and paste this little piece of code at the top of their perl scripts.

        Still, it's better than the alternative: Having to write a shell script every time you want to run a perl script (two files instead of one).

        Neither are true. Both can be handled automatically during install.

        I wish /bin/env would just allow me to pass command line arguments to perl. Why can't it?

        Oh it does

        $ /usr/bin/env perl -v This is perl 5, vers...

        The issue (Upd: with the shebang ) is that the OS passes everything after the first whitespace as one argument (Upd: to the command being launched ).

Re: Perl wrapper
by cdarke (Prior) on Mar 16, 2011 at 09:30 UTC
    For some reason, my carriage return characters aren't showing up in the text above

    Use HTML <br> line breaks.

      The above is explained in detail... right below where you're typing your reply!

      How do people fail to see read it?!

      A reply falls below the community's threshold of quality. You may see it by logging in.