Re: win32 perl script when you don't know where perl is

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

On Win32, "both" (that is, IndigoPerl and ActiveState Perl) Perl distributions install themselves in the path during the setup, and both come with the perl2bat.bat batch file, that (tries to) convert(s) any Perl program to a batch file.

The bootstrap code looks like this :

@rem = '--*-Perl-*--
@echo off
if "%OS%" == "Windows_NT" goto WinNT
perl -x -S "%0" %1 %2 %3 %4 %5 %6 %7 %8 %9
goto endofperl
:WinNT
perl -x -S "%0" %*
if NOT "%COMSPEC%" == "%SystemRoot%\system32\cmd.exe" goto endofperl
if %errorlevel% == 9009 echo You do not have Perl in your PATH.
goto endofperl
@rem ';
#!perl
#line 14
    eval 'exec perl -x -S "$0" ${1+"$@"}'
    if 0;    # In case running under some shell

require 5;
... Perl program begins ...
[download]

You could either simply use this, as any installed Perl is supposedly also in the path, or you could start from there with something crude like :

set DRIVES=c d e f g h
echo Scanning for perl.exe
for %%d in %DRIVES% dir %%d:\ /s /b perl.exe |find /i "Perl.exe"
[download]

and then let the user choose the version of Perl she wants to use. Note that people (or at least I) can have multiple versions of Perl installed, but most versions of Perl should be at least Perl 5 - so if your install script is self-reliant, you should be in the green.

perl -MHTTP::Daemon -MHTTP::Response -MLWP::Simple -e ' ;    # The  
$d = new HTTP::Daemon and fork and getprint $d->url and exit;#spider
($c = $d->accept())->get_request(); $c->send_response( new   #in the
HTTP::Response(200,$_,$_,qq(Just another Perl hacker\n))); ' #  web
[download]

Comment on Re: win32 perl script when you don't know where perl is Select or Download Code

Replies are listed 'Best First'.
(jptxs)Re: win32 perl script when you don't know where perl is by jptxs (Curate) on Jan 22, 2002 at 00:58 UTC
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	[reply] [d/l]
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;`	[reply]
(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	[reply]

In Section Seekers of Perl Wisdom