http://qs321.pair.com?node_id=140488


in reply to Re: win32 perl script when you don't know where perl is
in thread win32 perl script when you don't know where perl is

I'm starting to see how this can be done. A few points and questions.

- I will have an ENV var with the path where Perl will be
- I can use %HOME%\perl to get the right perl I think (trying now)
- I can also know what win32 I'm on in advance, or, at least, make a select the right vresion of a script

Questions:

what does the line perl -x -S "%0" %1 %2 %3 %4 %5 %6 %7 %8 %9 mean? Specifically all the numbered variables at the end...look like lines, but I don't know.

what do you mean by "In case running under some shell"?

I'm sorry if the questions are dumb. I literally know nothing about windows you can't see on the desktop...

We speak the way we breathe. --Fugazi

Replies are listed 'Best First'.
Re: (jptxs)Re: win32 perl script when you don't know where perl is
by $code or die (Deacon) on Jan 22, 2002 at 03:52 UTC

    I'm going to offer some different advice.

    Personally, I wouldn't count on perl.exe being in the path. I don't know about IndigoPerl, but the ActivePerl installation gives you the option of adding the perl/bin folder to the path, but it's not mandatory.

    I don't let setup programs add things to %PATH% (apart from a few special exceptions), because I want a bit more control over what gets executed, and where. So I generally add things to PATH manually, or write a quick wrapper to the executable that I want frequent access to. I'm not saying that it's a good or bad thing to do, but I don't think I am alone in guarding my environment variables.

    This is my suggestion: install your own copy of perl along with your commercial application. The Perl licenses (Perl Artistic License) allow for this. You should simply be able to compile your own version of perl, add the modules needed (check their licenses too.) and include those compiled files in the setup distribution of the commercial application. This has several benefits.

    • You know WHERE Perl is installed
    • You know THAT Perl is installed
    • You know what version of Perl is installed

    The downside is of course, that you increase the size of your distribution by several MB. If you need a reason convince the bosses, tell them that you will be able to provide better support for your software and clients. If your clients run Perl already, it won't break your application if they upgrade it or add modules, or uninstall it, etc.

    Just make sure you've covered all the licensing issues before you do this.

    Update: I've just re-read your original post, and you package Perl with the application already. So perhaps it's not too far fetched to just bundle a compiled version with only the bits you need. It may even reduce the overall size, and you won't clobber a perl installation that may already exist.

    Simon Flack ($code or die)
    $,=reverse'"ro_';s,$,\$,;s,$,lc ref sub{},e;$,
    =~y'_"' ';eval"die";print $_,lc substr$@,0,3;
      Actually, the crux of the problem is that I don't know know where it is installed. The user has the ability to install our software anywhere on the machine they like. So the tools/bin directories I need to find to get to our perl could be anywhere. Of course, all the other reasons you cite are why we do package perl in =] So I would say that's very good advice indeed...

      We speak the way we breathe. --Fugazi