Beefy Boxes and Bandwidth Generously Provided by pair Networks
The stupid question is the question not asked

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 ( #140529=note: print w/replies, xml ) Need Help??

in reply to (jptxs)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 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;
  • Comment on Re: (jptxs)Re: win32 perl script when you don't know where perl is

Replies are listed 'Best First'.
(jptxs) Re: (jptxs)Re: win32 perl script when you don't know where perl is
by jptxs (Curate) on Jan 22, 2002 at 08:06 UTC
    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

Log In?

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: note [id://140529]
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others cooling their heels in the Monastery: (3)
As of 2022-05-20 05:18 GMT
Find Nodes?
    Voting Booth?
    Do you prefer to work remotely?

    Results (72 votes). Check out past polls.