Category: Utilities
Description: Perl is a dynamic programming language created by Larry Wall and first released in 1987. Perl borrows features from a variety of other languages including C, shell scripting (sh), AWK, sed and Lisp. Structurally, Perl is based on the brace-delimited block style of AWK and C, and was widely adopted for its strengths in string processing and lack of the arbitrary limitations of many scripting languages at the time.
Perl Portable provides a portable installation of the open source Strawberry Perl distribution, including optional support of its ability to compile CPAN modules. The Perl binaries, scripts and essential modules are installed in the CommonFiles folder of the PortableApps.com framework for use as a 'library' of sorts for other PortableApp.com format applications which require Perl. The development tools for Module compilation are optionally installed in PerlPortable, including a launcher which will open a cmd shell (or suitable PortableApps.com alternative) with the required environment variables set to enable Module compilation.
Download Perl Portable 5.10.0.1 Development Test 1 [23MB download / 37(98)MB installed]
(MD5: 148ecaa36c145d301ed7f45c8dda5804)
Release Notes:
5.10.0.1 Development Test 1 (2008-06-11):
5.10.0 Development Test 1 (2008-04-03):
I'll grab this one at school tomorrow and post back. Because my internet is no fun.
Hmm the download didnt start so I had to look it up in the downloads table...
Have downloaded it now. Probably a mirror issue...
I had the same experience ..... not download available
Download works fine here. I'll test it later.
The developer formerly known as ZGitRDun8705
I ditto your whole comment.
I installed Text::CSV_XS through the cpan shell and Devel::Cover manually. Both went without a hitch. I haven't tried to run much from it yet. It looks like @INC is picking up the portable drive correctly.
I get some warnings from Term::ReadKey when launching the debugger. They shouldn't hurt anything, but it would be better if it ran cleanly.
One minor niggle is that CommonFiles/Perl/site has a Finance folder (Finance::Quote). This should be under site/lib. (Actually, it's there, too.) Maybe a packaging error?
From what I can see PerlPortable.exe is only needed to set up the path/environment for installing modules and isn't needed for running perl.exe itself. That's good.
Have you been working with the Strawberry Perl devs? It looks like at least one of them is interested in making it portable: http://use.perl.org/articles/08/04/14/1642215.shtml. Maybe you can collaborate.
Do you get the same warnings with Term::ReadKey using local strawberry perl?
The Finance folder in site is my fault, I probably copied it there at one point while testing since GnuCash Portable requires it. I'll fix that in the next release.
The entire PerlPortable folder is not necessary except to use CPAN or run perl scripts without having to set the path first. I would imagine most users wouldn't even install that part since it isn't needed to use perl with other Portable Apps. Other apps could easily just provide a module directory to insert into CommonFiles\Perl\site\lib if they need additional modules to work.
The portablization was modeled after some posts on perlmonks.org. It basically just replaces config mobules with equivalents that use environment variables instead of absolute paths.. so probably the "hacky" attempts that the post you linked mentioned. I look forward to his implementation so I don't have to make those changes
formerly rayven01
I don't have a local install of Strawberry Perl. It wouldn't surprise me to get the same warning though. I've seen similar stuff before with Term:: modules that the debugger can use but doesn't require. Setting the TERM environment variable to "dumb" (which is what it falls back to anyway) gets rid of the warning. 'tis a minor nuisance.
Here's a more substantial issue: I tried (and failed) to install PAR-Packer. The problem is that while running dmake Config.pm sees $^X as "perl.exe" -- it has a relative path instead of an absolute one. I have no idea why.
perl -e "print $^X"
gives me a fully-qualified path andperl -MConfig -e 1
doesn't die (which means it sees a fully qualified path too).The only thing I can think of is maybe dmake is in this case making use of one of the bat files in CommonFiles\Perl\bin. Those are the only changes I made which refer to perl with an relative path (basically they just call 'perl.exe' and rely on the PATH env variable being set right). In a standard strawberry perl installation all those bat files have absolute paths to perl.exe in the first few lines that are parsed as a batch file. If that's causing issues that's a big problem. There would be no easy way to update those absolute paths every time you run perl from a different drive letter without creating a "launcher" for perl.exe...
formerly rayven01
I was just skimming this http://prlmnks.org/html/567921.html earlier today which made me believe that $^X was always an absolute path on Win32. I have no idea how we've managed to break that. I've experimented with calling perl different ways and have never managed to get anything other than a full path.
I did a little grepping and (if your theory is right) the culprit might be xsubpp. It's used by the Makefile for PAR::Packer, uses Config.pm, and does some relaunch trickery with the -S flag and $0. It's all very suspicious but I haven't been able to recreate the problem in a minimal test.
An easy way to verify that should be to change the first few lines in xsubpp.bat (the actual batch part) to use an absolute path to perl.exe and see if it then works.
The batch/relaunch-with-perl thing they do with all those batch files looks pretty kludgey to me, but then I'm far from a perl guru and half the perl scripts I see look kludgey..
If that works we might get away with changing those batch files to use "%~dp0\perl.exe".
formerly rayven01
I tried changing both the batch call and the Perl
exec
one. I get the same error in both cases. I've been trying to grok the dmake output. I can't make out just where the error is occurring but I'm starting to suspect that it's something in PAR::Packer itself. If I can figure out enough I'll submit a bug against it in CPAN.Edit: I think that the hacked Config.pm is more to blame than PAR::Packer. Nonetheless, I sent a message to the PAR mailing list. Hopefully they can help me figure out what the root cause is.
In your PAR::Packer build, static.exe runs an embedded perl interpreter and therefore sets $^X to whatever it likes - in this case 'perl.exe'.
So, if you want to support embedded apps with certainty, you'll need a different approach.
For example, an embedded app might load Config.pm from any location, put anything in $^X, but during its build process expect Config.pm to return the valid locations for an installed Perl. Because that's what Config.pm does.
My suggestion would be that you decide not to attempt to support embedded apps in general and stick with $^X which will work for anything run via perl.exe.
Try building PAR::Packer in standard strawberry perl then installing the par dist in portable perl. I am fairly sure that pp and parl.exe will then work - so you can just distribute with portable perl.
That's what we'll be doing until strawberry perl gets native portability support. I saw a post by one of the devs that it was being worked on for the July update to strawberry perl, so hopefully in the future this won't be an issue.
formerly rayven01
The Perl Foundation has funded the addition of portability to Strawberry Perl via it's grants process, with the work expected to be done over the next three months.
If you wish, you can follow the process at
http://use.perl.org/~Alias/journal/
Glad to see you got some support. Once you get to the testing phase I'll package it up and get it out there as a new dev test.
formerly rayven01
5.10.0.1 is out.
Simplifying daily life through technology
Portable release updated to 5.10.0.1. PPM support, yay! That actually mostly negates the need for the CPAN compilation part of things unless you require obscure or custom modules. It puts it nearly on an even par with ActivePerl as far as ease of use (minus the GUI ppm installer).
formerly rayven01
The topic title has not been updated yet.
Simplifying daily life through technology
Installed it amongside PortableApps Platform in C:\Documents and Settings\Username\ppa\PortableApps\PortablePerl
When I launch it "C:\Documents" is not at runnable file (the error is in Norwegian bear with with this simplistic tranlation), I think it has something to do with the spaces in the path because its fully working if i move it to the root of my C: drive.
This should be a easy fix, but I can understand if you are waiting for strawberry to make it's perl native portable
cheers for a useful portable app once again!
I installed the package to D:\Temp\PerlPortable
Printing the PATH var showed me that there is an error in the location of the "Perl\bin" folder.
It is:
D:\Temp\CommonFiles\Perl\bin
But it should be:
D:\Temp\PerlPortable\Perl\bin
D:\Temp\PerlPortable\Data\Scripts>echo %PATH%
D:\Temp\PerlPortable\App\Strawberry\c\bin;D:\Temp\CommonFiles\Perl\bin;C:\WINDOW
S\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem;.;
Just wondering if this development is permanently put on hold, or if one could expect a new release anytime soon? I noticed that Strawberry Perl, now is available in beta as a portable app (Jan 2009), so I guess wrapping it with the PortableApp.com stuff could be possible?
I hope you are still working on this project!
Yep! One more vote for continuing the development of Perl Portable!
Hey Shawn, you still working on this, or do you mind if I start working where you left off?
Edit: Haven't heard anything yet, so i'm gonna start working on it.
Use the search box! Please!
Great man - I'm totally behind you!
http://strawberryperl.com/download/strawberry-perl-portable-5.10.0-alpha...
Strawberry Perl Portable is what he used. He put it in proper PortableApps.com format though.
Use the search box! Please!
I cannot get this to do a damn thing for me. All it does is open my script in notepad or tell me that "perl" is not recognized as a command or program.
What am I doing wrong? All perl tutorials, that I have found, are of no assistance to me. I just want to be able to run any script. A hello world script would make me more than happy.
Ripping my hair out. I am about to throw this in the trash.
---
skvmb