Integrating PHP and Perl
Perl is a language often associated with text processing and CGI. PHP is a language often associated with dynamic Web pages. Both are very popular with Web developers. Often, each of these languages is used at the expense of the other. Hard-core Perl developers would love to develop everything in Perl, and PHP developers tend to stick with PHP.
As usual in the Open Source world, there is a lot of zealotry between users of each language. If you think that one of these languages is perfect and the other is lame, this article is not for you! This article is for those who take a more pragmatic approach and use what works best for them. Each language has its strengths and limitations. Personally, I use both languages at work and at home. With time, I have discovered which language is best for which tasks and try to integrate the strengths of each language as much as possible to complete my work quickly.
Perl is extremely good at system administration and extensive data processing, among other things. This means, if you want to do some extensive processing on a text report, Perl would be preferable, as it provides handy regular-expression-enabled text comparisons, which make it so much easier to search through a report. Perl also has extensive string manipulation features. Perl, by virtue of being older than PHP and having an extensive community, has thousands of extensions archived in CPAN, which allow one to do virtually anything with the language, conveniently. From XML processing to writing to parallel port devices, CPAN includes everything. CPAN is the reason Perl continues to be useful to a large number of developers to date. Although it is not impossible to do everything described here with PHP and a mixture of other languages, it's simply more convenient with Perl.
PHP is extremely good at integration with Web pages and databases. PHP integrates nicely with static HTML Web pages. That's why it's so popular and has had more visibility than Perl in recent years. It has mature support for numerous popular free or non-free databases and supports MS SQL (MSSQL) server better than any other open-source language. From personal experience, I have tried at least two CPAN extensions for Perl to get it to work with an MSSQL installation, but with limited success. However, PHP has seamless support for MSSQL and uses it as natively as MySQL.
I was recently involved in a project in which nearly the entire project was in Perl. However, a tiny bit of code needed access to an MSSQL server. I knew how simple it was in PHP to work with MSSQL, and I did not want to go through the pain of setting up my Perl installation for MSSQL. That's why I searched the Internet for a way to integrate both languages in a manner that would allow me to use the best parts of each language and produce a coherent solution. And, I found the PHP::Interpreter CPAN module. PHP::Interpreter was perfect. It enables the complete integration of the two languages to an extent that one starts to believe that both are mere extensions of each other. PHP::Interpreter, as this article shows, allows you to use PHP's mature support for databases and other features natively in Perl, and also to use Perl's vast number of CPAN modules to extend your PHP programs.
According to AnnoCPAN, the module's main function is to encapsulate an embedded PHP5 interpreter. It provides proxy methods (via AUTOLOAD) to all the functions declared in the PHP interpreter, transparent conversion of Perl data types to PHP (and vice versa), and the ability for PHP to call Perl subroutines similarly and access the Perl symbol table. The goal of this package is to construct a transparent bridge for running PHP code and Perl code side by side.
To demonstrate the power of this module, we code two examples to show each side of the PHP::Interpreter, integrating Perl with PHP and integrating PHP with Perl. Each example shows areas in which both languages complement each other nicely to produce powerful code.
In the first example, we create an application to monitor failed logins through SSH to our system. SSH often is targeted by script kiddies and malicious users to compromise a system and gain access to it. The script identifies the IPs of the offenders, blocks all incoming packets from using iptables and, finally, logs them in to an MS SQL server database. We use Perl to do what it's best at—processing log files. It will continuously monitor the /var/log/messages file, which the SSH dæmon uses to log failed login attempts. To monitor a log file continuously, we use the CPAN extension File::Tail. To support writing to MS SQL Server transparently, we implement this portion in PHP and show how the two languages can be integrated seamlessly and used in scenarios where both complement each other.
Practical Task Scheduling Deployment
July 20, 2016 12:00 pm CDT
One of the best things about the UNIX environment (aside from being stable and efficient) is the vast array of software tools available to help you do your job. Traditionally, a UNIX tool does only one thing, but does that one thing very well. For example, grep is very easy to use and can search vast amounts of data quickly. The find tool can find a particular file or files based on all kinds of criteria. It's pretty easy to string these tools together to build even more powerful tools, such as a tool that finds all of the .log files in the /home directory and searches each one for a particular entry. This erector-set mentality allows UNIX system administrators to seem to always have the right tool for the job.
Cron traditionally has been considered another such a tool for job scheduling, but is it enough? This webinar considers that very question. The first part builds on a previous Geek Guide, Beyond Cron, and briefly describes how to know when it might be time to consider upgrading your job scheduling infrastructure. The second part presents an actual planning and implementation framework.
Join Linux Journal's Mike Diehl and Pat Cameron of Help Systems.
Free to Linux Journal readers.Register Now!
- Google's SwiftShader Released
- SUSE LLC's SUSE Manager
- My +1 Sword of Productivity
- Interview with Patrick Volkerding
- Managing Linux Using Puppet
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- Non-Linux FOSS: Caffeine!
- SuperTuxKart 0.9.2 Released
- Tech Tip: Really Simple HTTP Server with Python
- Parsing an RSS News Feed with a Bash Script
With all the industry talk about the benefits of Linux on Power and all the performance advantages offered by its open architecture, you may be considering a move in that direction. If you are thinking about analytics, big data and cloud computing, you would be right to evaluate Power. The idea of using commodity x86 hardware and replacing it every three years is an outdated cost model. It doesn’t consider the total cost of ownership, and it doesn’t consider the advantage of real processing power, high-availability and multithreading like a demon.
This ebook takes a look at some of the practical applications of the Linux on Power platform and ways you might bring all the performance power of this open architecture to bear for your organization. There are no smoke and mirrors here—just hard, cold, empirical evidence provided by independent sources. I also consider some innovative ways Linux on Power will be used in the future.Get the Guide