I am working with Koha — An Integrated Library System (ILS) written in Perl. I need to check the MIME type of each uploaded file for security purposes.
Some search results from Google suggest that we can do it with the help of the File::MimeInfo Perl module.
How can we install the File::MimeInfo module in Koha and check the MIME types, or is there some better way?
What I use is Image::ExifTool it can do a format check on some of the mime types and point out files with errors. Its not made as a security program so it can have some faults in that area, but its an active distribution.
You can install the module by placing the folder /lib in the modules tarball on the server then add this line of Perl code to your script use lib '/path/to/lib'; .
Related
My project wants to download files on Unix AIX from the AWS platform. I am trying to call cURL from within Perl script to server this purpose.
I am getting an error
Can't locate LWP/Curl.pm in #INC. Haven't been able to find libcurl.pm and curl.pm in respective directory of perl installation.
The version of Perl being used here is 5.8.8. I have read about this error and found that it requires libcurl.pm (7.10.8 version) and curl.pm modules installed in Perl's module library.
Going forward there is a plan to use cURL in combination with FTPS in order to download files from AWS. I have also read WWW library should be used instead of LWP from cpan.search.org. Can you advise which is better?
Also, if you could list the prerequisites of using cURL from within Perl script please?
The LWP::Curl module needs to be installed
It doesn't require libcurl.pm or curl.pm; indeed, there are no such modules
It does require WWW::Curl::Easy, but that will ordinarily be installed automatically when you install LWP::Curl
There are very many WWW modules and I can't tell which one you mean
I would normally recommend the regular LWP as it is the "standard" way of writing an internet client, but I don't believe it supports FTPS, so LWP::Curl should do fine
To install the LWP::Curl Perl library, you need to have libcurl and the C header files on your system. The WWW::Curl::Easy module will build against those, and the build will fail if you don't have them
That is all you need
You may want to consider LWP::Protocol::Net::Curl, which is very similar to LWP::Curl but it is a completely separate module by a different author and with different dependencies. It hasn't been updated as recently as LWP::Curl, but it is designed and tested as another LWP:;Protocol plug-in which can replace the standard protocols leaving LWP to work as normal. LWP::Curl doesn't seem to be quite as compatible
I would like to include a few additional .pl files in my CPAN module. These files are not essential to use the module, but are provide useful functionality/glue when the module is used in some common frameworks and applications.
Currently, I just include the .pl files in a "extras" directory of the distribution. This has the drawback that the files are not installed on make install. Is there a way to include them in the installation and where should they go? (They aren't executables and don't belong in "bin".) Would "share" make sense? Or are these kinds of files usually just not installed and it is left to the user to get them out of the .tgz archive and use as needed?
I use Dist::Zilla to manage my distribution.
I would suggest the following:
If they're actual complete programs or are almost complete, polish then up and make them standalone items that could go into /bin with POD of their own.
If they're utility glue, make a ::Utils module for them to live in and document their usage.
If these are useful code snippets but not something you can install somewhere or are sample usages or handy idioms, create a ::Cookbook all-POD module and include them there with the appropriate illuminating explanation for each one.
I don't know exactly how Dist::Zilla works, but the resulting archive has to be compatible with what ExtUtils::MakeMaker creates.
When you create a module with module-starter, it creates a module template using ExtUtils::MakeMaker. It creates several files and directories like the lib directory where your module lives and the t directories where your tests live.
One thing it doesn't create is a bin directory. However, if you create a bin directory, and you put files under this directory (such as Perl scripts), these files will be installed under the bin directory in your Perl's distribution and linked to /usr/local/bin or /usr/bin. Would this be a good place for your scripts?
I liked #Joe's answer, except that in my case the files were WebWork macros -- individual .pl files that make my module callable from WebWork end-user's code. So they don't fit under any of the categories discussed here, and as .pl files can't be made a module.
This is what I ended up doing:
put all .pl macro files into 'extras/WebWork' in the distribution.
add to "dist.ini" file a [ShareDir] stanza with dir = extras property.
now the WebWork admin can install my distribution from CPAN and then use perl -MFile::ShareDir -e 'print File::ShareDir::dist_dir("Statistics-R-IO")' to find the macros and make them available in WebWork.
I'm testing pdftotext as a part of poppler. It came pre-installed on the shared host that I'm using. I'd like to add the poppler encoding data which contain language packs to help combat errors such as "Missing language pack for 'Adobe-GB1' mapping".
Since it doesn't appear that I have permission to install the encoding data in the recommended directory on my shared host (/usr/share/poppler), how can I tell poppler where I've placed the data so that it will get used?
The pdftotext man page doesn't appear to describe any flags that would point to the data packages.
pdftotext resides at /usr/bin/pdftotext
Sorry, that seems not to be possible.
Assuming that your hoster uses Linux, the file relevant to reading the encoding data is GlobalParams. Lines 170 and 677 deal with initializing the base data directory and the paths for encodings, and these use compile-time hard-coded values for the base directory. There is no facility to pass arguments to poppler (and, as a consequence, to any package depending on it), and there also is no user-writable configuration file like for many other Linux software packages to change that behavior.
Your best chance is to ask your hosting provider to install these features for you. Many smaller providers will react friendly towards such a request. Otherwise, you'll have to change your provider.
I am trying to link against the libconfig++ library using cmake. I installed the library
using apt-get so I am assuming it will have a .cmake file so I can use find_package. Problem is I don't know what package name to use. I tried libconfig, config, config++ as the package name to no avail.
As a general question, how does one find out which package is associated with a library.
I know that find_package looks into CMAKE_MODULE_PATH to see if there is a .cmake script. How to I find out what is the value of CMAKE_MODULE_PATH on my system. It's not an environment variable. I am running ubuntu 12.04.
Any help is appreciated.
To use find_package you need to have corresponding Find or Config cmake file. But library may not to provide it, seems with your library is such a case. You can use find_library for finding libraries and find_path to find include directories. With these commands you can even write FindXXX.cmake yourself.
CMAKE_MODULE_PATH is not an environment variable, it is CMake's one. This variable is intended for you to set, if you have additional directories with modules, by default it's empty. This is used in the "Module" mode. In this mode CMake searches FindXXX.cmake in the CMAKE_MODULE_PATH (your modules) or in modules shipped with CMake and if it's found, it then used to find library and it's headers.
If that module wasn't found, it then switches into "Config" mode. On Unix it searches for ConfigXXX.cmake in the following directories:
<prefix>/(lib/<arch>|lib|share)/cmake/<name>*/
<prefix>/(lib/<arch>|lib|share)/<name>*/
<prefix>/(lib/<arch>|lib|share)/<name>*/(cmake|CMake)/
This files is shipped with the library, so there is no need to find anything, they contain all information, where library and includes located, etc.
About naming scheme, there is no standard one. You can look at Standard CMake modules. Modules found in internet for your library named FindLibConfig.cmake
For your case, library ships without corresponding cmake file, so you should write it your self (or find already written) and add directory with that file to CMAKE_MODULE_PATH.
I suggest you to read how find_package command works and how to write FindXXX.cmake files.
I am trying to set up an application dependant on few Perl modules, but the server I am installing to, does not have Internet connection. I read about offline module installs via ppd files, however I would have to resolve all the dependencies one by one.. All the more tedious considering I don't have direct internet connection.
I am hoping to find a solution, where I install ActivePerl on my PC and install all the libraries that I want and then copy paste the directories to my server. If it is just a matter of fixing some environment variables, that would be fine. Just want to know the definitive list of variables to modify. Not sure whether it is mandatory to install the perl libraries on the computer in which it is intended to run? (One is 32 bit platform and other one is 64 bit, but the server is already running various 32 bit applications so I hope it is not a major problem) For best compatibility, I plan to install ActivePerl on both the systems and merge the library directories to be identical.
The answer was on Perl FAQ, my bad didn't go through it properly.
I copied the perl binary from one machine to another, but scripts don't work.
That's probably because you forgot libraries, or library paths differ.
You really should build the whole distribution on the machine it will
eventually live on, and then type "make install". Most other approaches
are doomed to failure.
One simple way to check that things are in the right place is to print
out the hard-coded #INC that perl looks through for libraries:
% perl -le 'print for #INC'
If this command lists any paths that don't exist on your system, then
you may need to move the appropriate libraries to these locations, or
create symbolic links, aliases, or shortcuts appropriately. #INC is also
printed as part of the output of
% perl -V
You might also want to check out "How do I keep my own module/library
directory?" in perlfaq8.
From this link
Occasionally, you will not be able to
use any of the methods to install
modules. This may be the case if you
are a particularly under-privileged
user - perhaps you are renting web
space on a server, where you are not
given rights to do anything.
It is possible, for some modules, to
install the module without compiling
anything, and so you can just drop the
file in place and have it work.
Without going into a lot of the
detail, some Perl modules contain a
portion written in some other language
(such as C or C++) and some are
written in just in Perl. It is the
latter type that this method will work
for. How will you know? Well, if there
are no files called something.c and
something.h in the package, chances
are that it is a module that contains
only Perl code.
In these cases, you can just unpack
the file, and then copy just the *.pm
files to a directory from which you
will run the modules. Two examples of
this should suffice to illustrate how
this is done.
IniConf.pm is a wonderful little
module that allows you to read
configuration information out of a
.ini-style config file. IniConf.pm is
written only in Perl, and has no C
portion. When you unpack the .tar.gz
file that you got from CPAN, you will
find several files in there, and one
of them is called IniConf.pm. This is
the only file that you are actually
interested in. Copy that file to the
directory where you have the Perl
programs that will be using this
module. You can then use the module as
you would if it was installed
``correctly,'' with just the line:
use IniConf;
Time::CTime is another very handy
module that lets you print times in
any format that strikes your fancy. It
is written just in Perl, without a C
component. You will install it just
the same way as you did with IniConf,
except that the file, called CTime.pm,
must be placed in a subdirectory
called Time. The colons, as well as
indicating an organization of modules,
also indicates a directory structure
on your file system.