Im working on my final project in Perl. I'm creating an ASCII arcade game that will be ran through terminal. One of the specifications for the project is that our code must be able to run on the school's Linux boxes. Students do not have sudo privileges within the linux evironment so installing modules like Term::ReadKey or Curses would be tricky if not a impossible due to all of there dependency and requirements. So I'm looking for an solution within perl standard libraries or maybe someother work around. Thanks!
If you cannot use sudo, local::lib may be your friend, so you can install modules in your home directory, and no sudo is required.
With local::lib, you can install via cpan the modules you need, like Term::ReadKey.
Or perlbrew (http://perlbrew.pl/) if you have access to build tools.
Another workaround would be to use the core Unix Perl IO support.
e.g. select (perldoc -f select), to do non-blocking keyboard scanning (or set a timeout).
That's how I wrote a tetris clone in Unix/C 25 year ago :)
Related
I want a perl script that will install all the cpan modules automatically when running the perl script.Can you help this?
The CPAN client is just a Perl module which is wrapped by the command line tool. You therefore directly invoke it from a Perl script.
However, you may require system administrator priveleges to install new modules. One way to circumvent that is to use local::lib, or to ask the user for the necessary privileges. On Unixes, you could refuse to run your script if not run as root. However, that opens up many security issues and should be avoided if possible.
A fairly sane solution would be to require your users to install the cpanm client, and specify your dependencies in a cpanfile. Your users then just have to do cpanm --installdeps /dir/of/your/script.
But if we are already going through all that trouble, you might as well make a proper CPAN distribution. You don't have to upload it to CPAN, but you can distribute the tarball, and have your users install that. This has many advantages: Mature toolchains, automated testing, and wonderful helpers like Dist::Zilla that make creating a distribution a breeze.
Use CPAN::Shell, from the docs:
CPAN::Shell->install("Acme::Meta");
I'm a C/C++/Java/Unix geek by trade, but now I have to write a Perl program in Windows. So I've got Cygwin, Eclipse with EPIC installed, and simple test programs run. I do not have a Unix machine available to me that I can run Eclipse on.
But I need to use Net::TCP::Server and I can't figure out how to install it. It doesn't appear to be part of the Cygwin Perl install, and I don't want to spend 5 days learning the world of Perl and CPAN and Perl configuration. I just want to write my program.
Any simple ways of installing a Perl module in Cygwin? I'm thinking something like apt-get install would be nice, but I expect that's too much to hope for.
Thanks
$ perl -MCPAN -e shell
cpan shell -- CPAN exploration and modules installation (v1.9402)
Enter 'h' for help.
cpan[1]> install Net::TCP::Server
And it's instructive to list the configuration with the o conf command.
Seeing that some of the info here is a bit outdated and too complicated, I'd rather suggest the following. There are a few different Perl package managers in use. They are all installed with cpan (which is already part of the Cygwin Perl installation), like this:
# Install ppm (outdated)
cpan PPM
# Install cpanp (still used)
cpan CPANPLUS
# Install cpanm (most recent)
cpan App::cpanminus
Then you can install any Perl package you like, as for example in the OP, using cpanm:
cpanm Net::TCP::Server
Sometimes (as noted above) Cygwin may fail certain tests. For example, when using IPv6 on a machine only configured with IPv4, or when your windows firewall is blocking some tests, etc. To attempt to install anyway, try to use the force flag; -f.
cpanm -f Net::TCP::Server
I'm a C/C++/java unix geek by trade, but now I have to write a perl program in windows. So I've got cygwin, eclipse with EPIC installed, and simple test programs run. I do not have a unix machine available to me that I can run eclipse on.
You should be able to run Eclipse with EPIC right under Windows without Cygwin. I like Cygwin for many things, but it isn't exactly a very stable platform. Eclipse runs as a Java program, so all you have to do is make sure Java is installed on your PC. There is even a pre-built Eclipse package.
You can also get a decent Perl that runs right under Windows. Either ActivePerl or Strawberry Perl. Either one will work although many Unix heads prefer Strawberry Perl because it comes with the same MIGW environment that Cygwin has and many feel it's more compatible with the Unix Perl brethren. However, ActiveState Perl can use the Perl Package Manager (PPM) that contains pre-built modules. Unfortunately, the module you want isn't available via PPM.
But I need to use Net::TCP::Server and I can't figure out how to install it. It doesn't appear to be part of the cygwin perl install, and I don't want to spend 5 days learning the world of perl and cpan and perl configuration. I just want to write my program.
Installing from CPAN is really quite simple. The first time you run CPAN, it should pretty much configure itself. Then, to do an install, you run cpan install Net::TCP::Server and that should be it. However, I've tried on several Mac, Unix, and Linux machines, and I can't get it to work. So, this isn't a Windows problem as much as a problem with this module. It is fairly old, and might not work well in newer versions of Perl. You might have to force the install over test's objections.
Maybe you can use one of the already installed IO modules that come with Perl instead. That'll save you a boatload of trouble because the required modules are part of Perl's existing package.
Despite Cygwin's "problems," I use it regularly whenever I have to use Windows. I would recommend first installing a separate installation of Perl using perlbrew so that you won't interfere with Cygwin's copy of Perl in case something bad happens since Cygwin does not enforce root-user policy. In cygwin shell, type
\curl -L http://install.perlbrew.pl | bash
This should walk through the installation for perlbrew and set it up in one of your executable path. Next type
perlbrew init
perlbrew install --force stable
perlbrew switch stable
Wait a bit while a mint Perl is compiled. For unknown reason, Perl can only pass 99.23% of the core module tests on Cygwin (at least on my machine),hence the --force flag). My experience is that it mostly have something to do with handling of device files, like ports and pipes. I am unaware of people trying to resolve the issue as it seems like a Cygwin problem. Although it has not presented much problem for me with general system and web programming tasks. The module testing routines will fail if any problem exists so I am not fretting over it.
Next step is to install cpanm (cpanminus), type
perlbrew install-cpanm
From here on out, to install any library from CPAN, just type
cpanm [library::name1] [library::name2]
cpanm makes it trivial to install any Perl modules. You can even install from your local directory instead of CPAN.
Your mileage may vary, but I had a lot of trouble until I realized that Strawberry perl had a lot of bin folders in my PATH, and when I changed my .bashrc to export only a very simple PATH=/bin:/usr/bin:/usr/local/bin, Cygwin's perl installation's cpan started working beautifully. I used local:lib as Cygwin doesn't support sudo. Before it got into a bad loop saying "Press SPACE and ENTER to exit Patch" over and over.
There are multiple installers for cpan modules available; I know of at least CPAN.pm (comes with perl,) CPANPLUS, and cpanminus.
What is the difference between the three?
What situations call for using one over the other?
Are there other module installers I should know about?
CPAN.pm (cpan) is the original client. It comes with Perl, so you already have it. It has the most features. It has a lot of configuration options to customize the way it works, though virtually everyone accepts the default installation. It integrates easily with local::lib.
cpanminus (cpanm) is an attempt to make a zero-configuration client that automatically does the right thing for most users. It's also designed to run well on systems with limited resources (e.g. a VPS). It doesn't come with Perl, but it's easy to install. It integrates easily with local::lib.
Its biggest limitation is its lack of configuration. If you want to do something unusual, it may not support it.
CPANPLUS (cpanp) is an attempt to make a CPAN API that Perl programs can use, instead of an app that you use from the command line. The cpanp shell is more of a proof-of-concept, and I don't know of any real advantages to using it.
In summary, I'd recommend either cpan or cpanm. If you have trouble configuring cpan, try cpanm. If your situation is unusual, try cpan.
It's impossible answer this question because it is too subjective. :)
From my point of view: cpanm is the simplest way install perl modules. You can install cpanm with:
curl -L http://cpanmin.us | perl - --sudo App::cpanminus
and after it you can install modules with simple:
cpanm Some::Module
You can use cpanm for mirroring (part of) CPAN to you local machine too, so IMHO cpanm is the best for the most common CPAN needs.
Are there other module installers I
should know about?
If you're using a Linux distribution that packages CPAN modules, then it's worth using their package installation program to install modules. For example, Ubuntu/Debian have a huge number of CPAN modules that you can install using 'apt' and Red Hat/Centos/Fedora have a number that you can install using 'yum'.
CPAN is the standard. cpanminus (cpanm) asks fewer questions (best most of the time). I don't know anyone that uses cpanplus.
Since what these modules do is download, compile and install (place files in correct places) they all should do the same task. Some of the difference has to do with the permissions level you have. Perhaps you want to install some things local to your user and some things globally then you need a finer adjustment. Developers may also need to control/interrupt the process for debugging etc.
For daily use, use cpanm, unless you are too lazy to install it, then CPAN is fine.
cpanm uses much less memory. This makes it a better choice for environments where RAM is limited, such as shared hosting servers, where regular cpan might die before completing installation task, due to attempting to use more than available memory.
According to cpanm's (1.7044) documentation "When running, it requires only 10MB of RAM"
I am wanting to create an install script in the fashion of npm's (curl http://example.com/install.sh | sh) but it leaves me asking the question: can I just write the script in perl? As far as I know, perl is installed by default on at least ubuntu, RHEL & OS X - so I'm wondering in the year 2011, can I not write shell and still be generic enough for everyone? Is there a third and better option?
This would be targeting a user's development box, not staging or production.
What I want to do specifically is use this install script to bootstrap a development environment easily without the overhead of creating and maintaining packages. The script would have 4 steps:
check and make sure git is installed
use git to clone a repo to cwd
pull down and save a perl control script to /usr/bin, make it executable
add some environment variables (related post: linux cross-distro environment variable modification via script?)
That's it. My thinking is this is simple and generic enough to use a bootstrap script rather than a package. And my target audience is a user's unix or linux local development system.
The best option is to simply use the existing, well-oiled and -used (development) toolchain for the language the target app is written in. Not doing so frivolously discards the network effects gained from the ecologies that have grown around them.
C: GNU autotools
Haskell: Cabal
Perl: EU::MM, M::B, M::I
etc. etc.
Installing from the Web should be reserved for conveniently bootstrapping a user's system into the development environment.
Do tell more details about your software to get less general advice.
Edit: response to your addendum.
I dissuade you from a Web installer. This isn't bootstrapping an installation tool, this is plain installation of software and it should be done with with e.g. a Module::Build subclass.
I think perl is ubiquitous enough for you to write your installer in it. Shell is a lot more awkward anyway.
You might want to consider actually packaging your application as a deb or rpm or even using makeself rather than providing a raw script.
Here's a list of the various distributions of perl:
https://www.socialtext.net/perl5/distributions
Even if perl doesn't ship on every little obscure distro it's just an apt-get (or whatever) away. You might run into problems due to the various versions of perl installed however.
Use something like:
perl -E "$( wget -q -O - http://host/intall.pl )"
Also you can use
`cmd`
instead of
$(cmd)
but anyway, double-quote your choice.
I have been using perlbrew to manage multiple versions of perl on a Linux Fedora notebook. I have used it with great benefit to run command-line scripts mostly using App::cmd.
I now want to move to running web applications written using CGI::Application using different perls installed in my $HOME. I am familiar with running Perl web applications in $HOMEs using Apache's user_dir or creating Virtual Hosts but I am unable to come up with a clean way of integrating this and the perlbrew managed perls. Specifically I need help in understanding and finding answers to these questions:
How do install mod_perl under perlbrew?
Assuming this is done, how do I configure my VirtualHost so that it picks up the correct perl that is current?
If this is not possible, (which I doubt) can I at least use local installations to run vanilla CGI?
Thank you for your attention.
I don't think this is a good use for perlbrew, which moves around symlinks under its own directory. The trick is switching the mod_perl module around. Remember, mod_perl is going to be binary-incompatible between major versions of perl, and that you will have to compile it against apache for each version of perl (and apache) you want to use.
perlbrew really does two big things for you:
Installs perl, which is trivially easy to do on your own.
Switches around symlinks so perl is whatever version you want.
If you give up on that last one, perlbrew isn't really doing that much for you. I don't think the symlink feature is particularly valuable.
I think perlbrew is fine for what it is, but when you start doing things outside of its limited scope, it's time to not use it. It's supposed to be a tool to save you some time and headache, so if it's not accomplishing that goal, it's not the right tool for your situation.
In this situation, where I'm supporting a single, big web application, I give it its own perl installation that I don't let anything else use.
For your other questions:
markdown placeholder
You shouldn't have to configure any VirtualHost stuff. If you are using mod_perl, perl is already in there and you don't get to choose a perl. If you're using CGI stuff, you specify the perl on the shebang line. You will have to ensure apache picks up the right library directories, but I think perlbrew handles that. You might have to use SetEnv or something similar in your httpd.conf.
For vanilla CGI, just point to the right (symlink) path for whatever the default perlbrew version is. The CGI program will just use whatever perl that path points to.
See brian d foy's answer for why not to expect to use perlbrew to switch between versions of mod_perl. I also expect that you will need to run multiple Apache servers, if you need multiple different Perl versions under mod_perl.
However, using perlbrew as an easy way to build Perl is IMHO a valid thing to do, and there are few instructions available for how to run mod_perl under perlbrew.
First ensure perl is built with shared library support, by passing the -Duseshrplib flag (otherwise on 64-bit systems you will get a confusing build failure about -fPIC):
perlbrew install perl-5.16.3 -Duseshrplib
Install the development Apache libraries for your system. On Debian, this differs depending on the Apache MPM that you are using. For the prefork MPM:
sudo apt-get install apache2-prefork-dev
Or for the worker MPM:
sudo apt-get install apache2-threaded-dev
Then you need some options to build and install mod_perl2 into the right place. Note that this means cpanm will fail to build it, but you could use it to get hold of the source:
cpanm mod_perl2 # fails
cd ~/.cpanm/latest-build/mod_perl-2.0.8/ # adjust mod_perl version
Adjust the version of Perl below accordingly. (The MP_APXS option is to give the right path for Debian-based systems, which you might not need.)
perl Makefile.PL MP_APXS=/usr/bin/apxs2 \
MP_AP_DESTDIR=$HOME/perl5/perlbrew/perls/perl-5.16.3/
make
make install
Finally, change the LoadModule line in your Apache configuration file (adjusting paths accordingly):
LoadModule perl_module <your homedir>/perl5/perlbrew/perls/<your perl>/usr/lib/apache2/modules/mod_perl.so
Your mod_perl installation will now be running the version of Perl that you want. Install all your required CPAN modules and get going.