Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
The win32.perl.org web site provides references to several Perl distributions for MS Windows.
For a long time I have been using ActivePerl from
ActiveState but recently I switched to
Strawberry Perl.
IMHO The only advantage that Active Perl still has over Strawberry Perl is the fact that it comes with Perl Tk which means its easy to install
Devel::ptkdb the graphical debugger. Other than that, I think Strawberry Perl has all the advantages.
Strawberry Perl is just getting better and better. One problem I've repeatedly had with ActiveState is that my modules sometimes fail to install because I need an upgrade to a core module, but they won't allow that. Thus, everybody who doesn't use Windows can use my code, but they can't do that with ActiveState's Perl.
ActiveState also has a very dodgy build system which often fails to report exactly why a module failed to build. I got so tired of emailing and asking for this information that I eventually gave up. I want my code to run on Windows, but if ActiveState doesn't provide me with that information and doesn't give me any option for upgrading core modules, I just can't use it. Some of my modules have NO build failures on any operating system -- except those with ActiveState Perl. Support Strawberry Perl and just don't worry about ActiveState.
If ActiveState has fixed their build system and their 'no upgrade to core modules' policy, it's worth revisiting.
There is no single-best Perl distribution. Vanilla Perl (relocatable, redistributable Perl), and it's more-developer-friendly Strawberry Perl have significant potential.
However, there is a very good reason why ActivePerl is so very popular. The advantages mostly come in the form of ease of deployment for your end users (no compiler necessary to use their package manager, PPM). The ActiveState PDK (Perl Development Kit) is also a very nice way to pack a complete Windows binary that doesn't require any Perl to be installed on the user's machine.
Unfortunately, many very nice CPAN modules (like the Perl bindings for OpenSSL) are not available via ActiveState's repository.
Like most things, you should make your selection based on which distribution best meets your needs.
I primarily use ActivePerl, but I really like where Strawberry Perl is headed. I love that the cpan shell "just works" and I don't have to jump through a bunch of hoops to install XS modules. (e.g. ExtUtils::FakeConfig, though that's less necessary in more recent ActivePerl builds.) I'm also excited about the possibility of Perl on a thumbdrive. The dev release of Portable Perl is pretty usable already.
I agree that the main advantage of ActivePerl is Tk out of the box, but note that as of 5.10 ActivePerl no longer ships with Tk by default. It ships with Tkx instead.
The future is definitely Strawberry Perl.
Whichever you chose though (and this problem is not unique to Windows), if you're distributing the end result to other machines, you're going to have to be careful as regards the installer/installation instructions you provide.
Strawberry Perl is more like Perl on *nix. It comes with MinGW which could be useful on its own. The Perl modules can also be installed with either ppm or cpan.
I always use Cygwin (xterms with bash are so much better than cmd windows) and the Perl that comes with it. I install Perl modules with the CPAN shell (the "cpan" command); it works fine.
I by far prefer Strawberry Perl. For one, it installs gcc as part of mingwin, so that you can install directly from CPAN.
I used ActiveState's perl for awhile, but I had a lot of flakiness from one machine to another despite them being (seemingly) identically configured. Their PPM module packaging left a bad taste, also. It makes it dead-simple to manage packages, but you rely on them to update PPM after CPAN updates. Also, PPM is not by any means the full content of the CPAN; The last time I'd used ActivePerl, I had a hard time finding all of the modules I needed, and the ones that were there were often an old version.
ActiveState Perl has been considered the de facto Windows Perl for quite a while. While it has a lot of flaws and a lot of us use something else, it remains very popular. If you were building Perl code to be executed on a Windows machine (other than your own), I would consider writing it with an eye towards a default (or as default as I could get it) AS Perl installation executing it. Anything else and you are introducing barriers to entry for others trying to use your app later.
I had major problems with Strawberry, and I felt there was no support. The good people at PerlMonks couldn't help me, and I gave up. If this page leaves you with a certain lack of confidence, there's your answer.
The code I write lands in Fortune 500 companies so a "corporate" feeling is helpful. I've used ActivePerl so far, and it's worked fine for both internal tooling and for distribution to those large'ish customers.
I am using Active State Perl 5.014, which works OK.The problem is, it doesn't have the latest version of Padre (the IDE, debbugging environment).
Related
Instead of having a different download of a program for Windows and Linux, would it be possible to make the download be a cross-platform script/executable that can download the correct installer from an FTP server and start that? What language should I write it in? The only one I can think of would be Java, but I don't want to take the time to learn it. I can't write it in Python or BASH, because most Windows machines don't have these installed. How should I do this?
Cross-platform executable(like an exe or a.out or ELF) is out of question. An executable is never cross-platform when Windows is involved. The scripting languages(or JIT compiled) have to be brought in for this purpose. We are in a CHICKEN-AND-EGG paradox. You may have to detect the OS the downloader is using, using a Javascript script in your website page and decide on what is to be done next etc...
Although not exactly what you are looking for, below are some pointers.
The best tool I know of, for multi-platform installers, is Flexera Software's InstallAnywhere. That might be a bit costly. For free options I would look into options like:
PERL
PYTHON (but this is out of question as per your post, but look at the end of my post for more options for Python)
Although writing the installer in any of the above languages might mean a lot more work, they provide you unmatched flexibility and complete control.
Perl requires that you install Perl interpreter and modules on Windows. But this also seems to be out of question for you. So you may avoid the headache by looking into:
PAR
pp
For Python go through:
py2exe
pyinstaller
So I ordered Learning Perl 6th edition and I know it's using 5.14, but Strawberry Perl is only at 5.12, so what are my options? Is 5.12 fine for it or will there be problems with what's being taught?
Is my only option using Linux? If so distro suggestions would be good along with instructions or a link to instructions on updating perl in said distro (or in general). I'm relatively new to Linux, only ever having installed Ubuntu a few times and never really stuck with it. The perfect solution would be a distro that's good for installing on another PC in my house so I can just remote desktop (or equivalent, even SSH, though GUIs are nice) into since I have an older PC that I want to put a new hard drive in and mess around with. (Pentium 4 with a bit less than a gig of RAM so not awful)
Hopefully this question is considered more constructive than my last two and I look forward to your responses.
Edit: Also any resources for a Linux noob would be a great help if possible and if it's the best option.
I haven't actually seen Learning Perl 6th edition, but I would be very surprised if you had difficulty working through it with Perl 5.12. Perl 5.14 is still too new for most people to be writing code that requires it. The book may mention some features that you can't take advantage of in 5.12, but it should still explain how to accomplish things using only 5.12 features.
I would recommend just using the current Strawberry Perl and not worrying about the version number.
Update: As Mike pointed out, here's the opening paragraph of the Preface:
Welcome to the sixth edition of Learning Perl, updated for Perl 5.14 and its latest features. This book is still good even if you are still using Perl 5.8 (although, it's been a long time since it was released; have you thought about upgrading?).
So that confirms you'll have no problem trying to use 5.12 with the 6th edition.
Use ActivePerl
It is a very good product, it is free, and it has a reliable (for the most part) PPM (Perl Package Manager). I use it and have no troubles usually. It is a binary distribution just like Strawberry Perl, but you use PPM to get modules instead of CPAN.pm.
Note: If you are getting Perl 5.14 Just because of the book, don't. I got that book (I am also a beginner) and used 5.12.4. You get mostly all of the features (except for a few ;-)
I moved from Windows and PHP to Linux and Perl a while ago, and haven't looked back - but I don't want to start an OS or programming language war here. My desktop is running Ubuntu, but you could stick with Windows (I have Windows available in a VirtualBox VM for those times when I need it).
You can download the Ubuntu Server ISO and attach it as a CD/DVD image via the Virtual Media Manager. You can then set up as many Ubuntu VMs as you like. I use very basic setting for mine:
RAM: 512MB
Hard Disk: 8GB dynamic
Network Adapter: Bridged
I have a few images configured. One is setup with Nginx + Catalyst, one with Bricolage CMS and Apache, and a few other variations (including a PHP one). The great thing with VMs is that you can create snapshots, duplicate images, experiment, and blow things away and restart if you mess things up.
How you choose to setup your development environment is down to personal choice. I use SSHMenu to open four SSH connections to my development server - this also places the terminals at predefined positions on my screen.
I use one terminal to run code, access the debugger, etc. I use another for connecting the DBMS client (PostgreSQL / MySQL). I use the other two for editing code and unit tests. I use Vim in the terminal as my editor. I was going to try Emacs too, but never got round to it.
I use git as my version control system, with bare repositories on a separate file server. I did start with Mercurial, but it appears as though much of the Perl world is using git, so I switched.
I have configured the GNOME terminal to use the beautiful Solarized colour scheme (you can find a handy script for that here).
As for the Perl version: I don't know. I agree with other comments about using a standard package rather than trying to build your own - especially if you are a Linux newbie. I've just looked on the O'Reilly preview page, and in the Preface, it says "this book is good even if you are still using Perl 5.8" - so you should be okay with an earlier version. You also need to be aware that if you are planning on doing web development in Perl, you may be limited to older versions of Perl by your chosen hosting provider.
A few more thoughts:
Programming Perl, despite its age, is still a great resource. One you've completed Learning Perl, and perhaps Intermediate Perl, it's well worth reading. The section on Pattern Matching (regular expressions) is fantastic.
Modern Perl is a really good read. It's well written, concise, and full of really useful tips.
cpanm is a great alternative to the standard CPAN application.
local::lib is very useful. I use it to create a per-application set of CPAN modules. This means that I can simply copy the entire directory structure from my development server to the application server, without having to worry about conflicts with other applications that might be using different versions of the same modules. This is probably not relevant to you at the moment, but when you've learned more and start using lots of CPAN modules, it can be really handy.
A quick local::lib example:
mkdir -p ~/myapp/extlib
cpanm --prompt -L ~/myapp/extlib CPAN::Module1 CPAN::Module2 ...
eval $(perl -Mlocal::lib=~/myapp/extlib/)
In ~/myapp/scripts/myscript.pl:
use FindBin;
use local::lib "$FindBin::Bin/../extlib";
You could
Install Windows and then run Ubuntu inside a VM on your Windows machine. You can start it up, ssh to it and then mess around with it.
Use ActivePerl.
Simply use ActivePerl - you can download 5.14 or 5.12 and it's as good as Strawberry, even with the complete CPAN toolchain, nowadays. The only limiting factor is the license, it's absolutely free to use but you can't bundle it in any of your apps without getting an OEM license. So for 99% of the cases this is a good distribution.
StrawberryPerl is also suitable, but they usually have a slightly longer delay between the release of a Perl version and the availability of an updated StrawberryPerl version.
I have a fully updated Ubuntu 11.04; it has Perl 5.10.1. I don't know how up to date other Linux distributions are. Cygwin also has 5.10.1.
You could always build from source.
Well, you can either use Active Perl, or use a GNU/Linux distro and get the latest Perl from it's repos. GNU/Linux is not Windows, it is open-source and you can install it on as many PCs as you want it. You could try Ubuntu or it's builds for an easy-to-use system.
Most of Learning Perl doesn't depend on Perl 5.14 features, and those that do are clearly marked. In most cases, I try to show a non-v5.14 way to do the same thing. You'll miss out on some nice v5.14 features, but you won't be stuck without them. And, for what it is worth, the new Programming Perl, due very soon, covers up to v5.16. Don't buy the old version if you don't have it yet.
Many people have already suggested very good options for various Perls, so I won't repeat those. My advice to students is always to learn on the Perl version and operating system you want to deploy to.
You don't have to stick to Windows. You can get a virtual machine of just about any operating system you like. VMWare and Oracle VirtualBox have free players and many places offer pre-configured virtual machines. From there, you can install any Perl version that you like. It's also incredibly cheap and easy to have multi-boot systems (although a VM doesn't prevent you from using both at the same time).
On Windows, you can also install cygwin, then install any Perl that you like.
Also, there is a preview release for Strawberry Perl 5.14.
This question already has answers here:
Closed 12 years ago.
Possible Duplicate:
Which version of Perl should I use on Windows?
I want to install Perl for Windows and according to http://www.perl.org/get.html there are two options: Strawberry Perl and ActivePerl.
Which is better and easier to use?
ActiveState is usually easier unless you need a module (or newer version of a module) that isn't built for it. I'd generally go with Strawberry since I always end up wanting to use an obscure or new module at some point.
Strawberry Perl is the better, more modern, choice.
AcivteState sells support for ActivePerl, so if you want commercial support, that is the way to go. Strawberry Perl is nice because it includes everything you need to install most modules from CPAN. They are both equally easy/hard to use. I would suggest looking at Padre (a Perl IDE written in Perl 5) if you are new to Perl. The installer includes a copy of Strawberry Perl.
Between the two I won't make any comparison, but in addition to those, you can also take a look at Cygwin.
I've used both (though not extensively), and I've found that Strawberry Perl offers the best experience when installing packages (things tend to Just Work), but ActiveState has better support for integration with Windows (e.g. the .pl file extension is registered automatically upon installation).
Note: I haven't used a recent version of either (recent being in the last year).
There is no real difference between recent versions of ActiveState Perl and Strawberry Perl from my perspective. (BTW, that is a great achievement on the part of the Strawberry developers).
You can install the same mingw tools and dmake with ActiveState and compile most XS modules successfully.
And, you can use ppm with Strawberry Perl.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 8 years ago.
Improve this question
Linux utilities like sed, awk and other shell scripting features are awesome and life becomes a lot harder when I am developing on windows and cant use any of these.
People suggest to use cygwin for those who want the linux like tools under windows. But I feel cygwin will be an overkill for someone who only wants to use the handful commands.
Some say that Windows Services for Unix can also be a good alternative.
I have used none of these. Can some experienced programmer suggest best/simplest way to do this? of course apart from switching to linux itself.
I think the GnuWin32 project is exactly what you're looking for. Unix command line tools ported to Windows.
I've been using UnxUtils which are ports of common GNU utilities to native Win32 for ages.
I should add that I've also used Cygwin (et al.) and Microsoft's Services for Unix and neither of them were any good for me because they don't work as well as native versions from the command prompt, and using ksh/bash/whatever under Windows never really works right, even though I use ksh under unix all the time.
I tried something like this quite often, but to be honest, none of it really works well.
I therefore suggest using a virtual machine (such as VirtualBox) and install a small linux inside that. You can easily move files from and to the guest system with shared folders.
Judging by my experience, it is the best solution I used so far.
I tried Gow for some time, and it's nice. It offers 130 Unix-shell utilities for Windows. The contextual menu in the File explorer, to start a prompt in the current folder, is really handy.
There's a GNU port of many of the utils. I find that quite useful.
If you need Perl, I recommend Strawberry Perl.
The problem with most of the tools suggested here is that they don't get updated very often E.g. the last update GnuWin32 got was on 27 December 2010; UnxUtils was last updated on 01 March 2007.
I suggest MSYS2, a very good option which has a Win32 port of Arch's pacman package management system built-in. It's a spin-off from Cygwin like MSYS but much better than MSYS (lots of packages and gets updated almost daily) and (very light as opposed to) Cygwin.
It's a rolling release distribution that works under Windows and thus you get the latest and greatest of the packages. MSYS2 additionally has MinGW, provided in both x86 and x86_64 flavours. They've their own list of packages - MinGW packages.
Maintainers are very affable too.
MSYS is a common alternative for people who find CygWin excessive. It's still a special prompt, but it was originally intended to set up just enough Unix-compatibility to build programs using the MinGW compilers and the typical configure/make routine.
Using tools like sed and awk isn't going to work quite as expected in a normal Windows command prompt. It can be done to a point, but common usage involves command-line syntax that is normally interpreted by the shell, but which the Windows command prompt doesn't support. One example is wildcard file specifications. I've often found that Unix-centric tools aren't as usable on Windows as they assume the shell has expanded those wildcards into lists of files for them.
Install msysGit (netinstaller), it comes with a (msys/minGW) shell environment.
It also adds a "open shell here" in explorer.
It's faster than Cygwin, but at the sacrifice of unix compatibility.
Maybe it is stupid, but I usually search google for i.e.: "indent windows". You can select tools from mixed platforms. Lot of stuff from open systems has been ported on windows.
This question already has answers here:
Which version of Perl should I use on Windows? [closed]
(11 answers)
Closed 7 years ago.
I'm totally new to Perl, but I'd like to try it out. I read about two rival distributions available for Windows platform (I guess there's just Perl on other OSes :).
Wikipedia says that Strawberry Perl comes with additional development tools to compile CPAN modules if necessary. It sounds pretty good to me.
It also says that ActivePerl has a lot of prepackaged modules which are easier to install with PPM. It sounds great too!
There's a clear trade-off between those two. And I wonder: What should I pick to get started? If I pick one how hard, is it to migrate to the other?
I gave both distributions a run for a couple of weeks. I actually liked both which is a good thing! One can't go wrong with either of these. I ended up going with ActivePerl simply because it comes with offline documentation(in HTML) - a great life-savior for those who are on the road or just not always connected. It was super-easy for me to get started with Perl language while I was on vacation when I wasn't always online.
Strawberry Perl is at least as great if not greater. So I can totally recommend it, too. And I have to say one should just learn Perl - it's a very beautiful language. Give it a try!
Strawberry Perl uses CPAN, which means that you are up to date as far as modules are concerned. When things are added to CPAN, you have immediate access to them. Strawberry Perl also comes with MinGW which means that Strawberry Perl can use quite a few XS modules directly from CPAN without any modification. The MinGW distribution comes with gcc, make, ld and other tools to help you build modules. I think Strawberry Perl also comes with a few modules that let you install PPMs (Perl Package Manager files).
ActivePerl installs modules using its own format called PPM (Perl Package Manager). The official repository is hosted by ActiveState. You can find PPMs for most of the popular modules so you shouldn't have any trouble unless you are looking for an obscure or really new package (so bleeding-edge stuff won't work because PPM usually lags behind CPAN). Although easier to install than CPAN modules, PPMs are specifically created for Windows and so some CPAN modules will not work (because they do Unix-specific things).
I have used both before and it seemed to work for most cases. But I lean towards Strawberry Perl because the environment is closer to Unix and so there are not many incompatibilities. On the other hand, ActivePerl is made for Windows and so it works with Windows very well.
Another option is to install Cygwin and Perl that comes with Cygwin. I have done that before and it works reasonably well. You also get access to CPAN.
Pick what you think works best for you.
Amplifying just a tiny bit on Vivin Paliath's helpful answer:
ActivePerl / PPM pros: If there's a PPM for your version, it's going to work, and simply.
ActivePerl / PPM cons: There's not always a PPM, or at least not always an up-to-date one.
Strawberry Perl / CPAN pros: Your repository is CPAN, not a bunch of binaries maintained by third parties. You have new modules the moment the author releases them, and you're using the build system that the author intended.
Strawberry Perl / CPAN cons: Not everything is guaranteed to build perfectly with the Windows tools.
Strawberry Perl / CPAN mitigating factor: The Strawberry developers try really, really hard to make sure that everything goes smoothly and that as much of CPAN as possible is available to you, and when modules are identified as trouble spots (difficult to build on Windows, but required for other popular modules/applications), they'll either work with the author to get the module fixed so that everyone can install it, or in exceptional cases, apply their own fixups and bundle the module with Strawberry Perl or Strawberry Perl Professional.
My preference is with Strawberry Perl. I appreciate what ActivePerl is trying to do, but I think it's a bottleneck in the development process. They were necessary before the community got together and built Strawberry Perl to bring Windows into the "first world" of the Perl ecosystem, but they're not necessary anymore.
After having used both for years, I'd say, for me at least, ActivePerl is a much more convenient choice. The PPM installer included in ActivePerl allows you to add alternative PPM repositories which will give you access to almost all useful Perl modules available on CPAN - but prepared and tested for Windows. This was for me, in the long run, a much better (and more robust) choice. Even for the Windows version of the Apache HTTP server, there is a precompiled mod_perl (2.0.4) ppm available which will (did for me) work out of the box with ActivePerl 5.12.1 and Apache 2.2.15.
I think I dropped Strawberry Perl after trying to install DBI + DBD::mysql on Windows 7 (which is a no brainer in ActivePerl; just click on the ppms and choose install).
But maybe that's solved by now. And maybe one can choose the directory where Strawberry Perl gets installed (I couldn't).
BTW: for compiling your own Inline or XS stuff, just install the MinGW compiler by ppm (I didn't do that, but it looks interesting).
Addendum: after reading the comment below, I checked Strawberry Perl again and it's now possible to change the installation directory, which is a denoted feature of the 5.12.0 release (which is the actual version). This would solve one important (IMHO) disadvantage of Strawberry Perl (compared to ActivePerl).
Strawberry Perl is more Unixy in its approach, and I have been always very happy when I've worked with it.
ActivePerl, however, due to its custom package management system, has been a colossal pain when I've worked with it. This matters when you're in an enterprise environment.
For just messing around, IMO, Strawberry Perl is better. /subjective
Both are great and work the same. Strawberry Perl is known for being able to build XS modules, but you can do that with ActivePerl too if you just install the Visual Studio SDK (or the free Express version).
For that matter, if you have access to Visual Studio, the best you can do is to build Perl from source (it's pretty easy if you read the README) and keep building your modules with the same compiler. That's actually a better idea than having a mixture of compiler/modules.
One thing you have to consider if using ActiveState: If you install it on a server facing the Internet, then you are required to buy a Business license ($1000/year/server as noted by Ron Warshawsky). It doesn't mean it won't work; it's only a matter of being a requirement in the EULA. Many people don't know this and have it installed on Internet-facing servers without buying the corresponding license.
ActivePerl excludes tons of modules from Community edition and building them under Windows is a real pain.
Also, they would let you download and use only latest editions for free. Everything else, like access to 5.8.8 or to earlier version of modules is either Business ($1000/year/server) or Enterprise edition (per quote).
In a perfect world, I'd choose debian-interix or pkgsrc-interix Perl (not the ancient Perl that ships with Interix/SFU/SUA) since it provides the most POSIX / UNIX -like system (including real copy-on-write fork, not Windows fork emulation from Cygwin).
I have in the past (and it is installed on Windows machines here), but not everyone can / will install SFU/SUA just for Perl. In those cases I'd recommend ActivePerl, primarily for the interface's familiarity to Windows users (PPM graphical shell versus CPAN) and its integration with the Perl Dev Kit (PerlExe, PerlNET, PerlSvc, and friends).
Also, contrary to what others have answered, you can use CPAN (and the CPAN shell) with ActivePerl (though it does involve installing the necessary development tools via PPM first) if you need it.
If Larry Wall uses Strawberry Perl so should you. ;)
If you design your application right, it shouldn't matter which you choose.
A big point might be the versions of various modules that each can provide, or not provide. PPM packages can lag behind CPAN releases, but if you aren't careful, bleeding-edge CPAN releases can break backwards compatibility. Furthermore, sometimes there will be PPM packages for things that just won't build properly under Strawberry Perl (though this implies that the module is poorly designed more often than not).
Just be aware of the versions of any modules you use, and you should be fine, regardless of which you choose.
If you are using the box.com client to sync files, then you probably want (at least at the moment) to go with Strawberry Perl. The ppm executable conflicts with one of the Box.com DLL files. The GUI will not start at all (yielding a Windows message that the "perl ... interpreter has stopped working".) I have also had intermittent problems using the command line version of ppm when the Box.com client is installed.