Please create an account to participate in the Slashdot moderation system


Forgot your password?

PHP and Perl in One Script? 174

gbulmash asks: "Recently, I began working on a graphics project and wanted to use ImageMagick. As a PHP coder, I figured I'd use MagickWand for PHP. But after some investigation, I decided that an alpha at 0.1.8 with sparse documentation just wasn't going to be good enough for production use. I decided that PerlMagick would be a much better API, but I didn't want to code the whole project in Perl. In the end, I found a cool package for embedding Perl code in PHP scripts (with an article on its use) and it went to a 1.0.0 release, earlier this year. I think I've found my answer, but before I make a final decision and go ahead with it, I thought I'd ask the knowledgeable Slashdot crowd: Is there a better way of interfacing Perl with PHP so you can get the best of both worlds?" So you've got Perl in your PHP, is there a way to do PHP in your Perl?
This discussion has been archived. No new comments can be posted.

PHP and Perl in One Script?

Comments Filter:
  • A bit extreme (Score:5, Insightful)

    by Bogtha ( 906264 ) on Friday June 23, 2006 @07:29PM (#15593365)

    Why didn't you use the ImageMagick extension in PECL []? There's plenty of image processing options with PHP, just because MagickWand didn't work out for you, that doesn't mean you have to concoct a monstrous hybrid of PHPerl.

    • Re:A bit extreme (Score:3, Interesting)

      by kv9 ( 697238 )
      wow, it's when i see questions like these that i realize what kinda people code PHP and give it such a bad name. first of all, you could have just used the PECL extension as suggested above, which *will suffice*. or, in the worst case just exec() the binaries, like any normal person would do. not bringing Perl into the equation. what in the name of doctor frankenstein?


  • I thought this was already publicized, Perl & PHP in one script? Isn't that just a brain fuck [] :)
  • by Anonymous Coward on Friday June 23, 2006 @07:33PM (#15593377)
    Instead of going with some bizarre rube-goldberg hack like this (does it even work with dynamically loadable Perl modules?), just write a separate Perl script that does what you need and receives data on standard input and gives responses on standard output. Use PHP's proc_open() function. You can even set up the Perl script as a daemon, if you like, and get higher performance.

    I used this same trick to interface a binary-only executable to my PHP script. You can even use XML to pass the data back and forth, if you swing that way. I don't know how this might work on Windows, if that's what you're running on.

    By the way, version numbers mean absolutely nothing except the author's opinion of his own software. In fact, the article you posted says: "the extension is still marked EXPERIMENTAL". Sounds like alpha to me.

    Not to mention, this is the same guy that wrote Turck MMCache and in my testing, mmcache couldn't stay stable for more than a day or two, and would randomly return junk characters instead of output from our PHP scripts. Not exactly an author I'd trust for this kind of lower-level stuff. (Yeah, I know, there are 10 billion geeks who used MMCache on their 5-hit-per-day blog and it worked perfectly, and will not hesitate to point this out. It just didn't work for me, and other products did, sorry!)

    For what it's worth, I've used "pecl-imagick-0.9.11" on my Gentoo servers to manipulate images (basically, to generate thumbnails by resizing and sharpening) and it works perfectly. I think this is different than what you're talking about. So unless you really just can't live without Perl (?), try that first.

    Instead of looking at version numbers, test thoroughly.
    • Turck MMCache (Score:3, Interesting)

      by rodent ( 550 )
      I have to say I used Turck MMCache on an 80 server farm serving up >4 million page loads (not hits) per day with not a single problem. This was back in the PHP4 days. Based on the load on the machines it could have easily been done with 5 but management wanted to spread the risk in an insanely large manner.
  • by heinousjay ( 683506 ) on Friday June 23, 2006 @07:50PM (#15593467) Journal
    All the security of PHP and all the readability of Perl? It's a surefire win. I wonder why the whole world hasn't caught on to this one yet?
  • CPAN! (Score:3, Informative)

    by schweini ( 607711 ) on Friday June 23, 2006 @08:09PM (#15593588)
    as almost always, CPAN is your friend [] in all things perl-related.

    aside from that, i really don't understand why you'd use PHP if you're familiar enough with perl to use it.
      1. Perl using standard CGI is slower than PHP's mod_php
      2. Perl using mod_perl is more complicated than PHP's mod_php

      mod_perl really is a big issue. In PHP, something that runs under two identical setups, one that uses mod_php and the other that uses PHP CGI will run identically.

      mod_perl's caching and function wrapping can lead to unexpected results with global variables and modules (See: perldoc FindBin).

      • Meet Embperl []
  • by Anonymous Coward on Friday June 23, 2006 @08:13PM (#15593609)
    I'm probably going to get flamed for this but have you considered using rails? Seriously, you just spend a couple of hours installing it on your development box before you discover the speed and power of rails. Then when you've used the programming equivilent of a lumphammer to sculpt your fine detailed script, you get to spend the next week looking for hosting. I do all my development on a gentoo box, it only took me a weekend to set up from stage 1. I have some great USE flags that make my RAILS development go super fast and gentoo only takes about 1.5 hours a week to maintain. Well, sometimes it takes a little longer because the QA is non-existent of late.

    That's what I'd do anyway, RoR running on gentoo with some kicking USE flags. I'm developing a complete Ajax OS in my spare time using this system. It's going to revolutionize the OS market and yes, it will have use flags.
    • I'm writing a processor in RoR, wanna cooperate? :P
    • you get to spend the next week looking for hosting

      dreamhost [], which has RoR hosting :)
  • So you've got Perl in your PHP, is there a way to do PHP in your Perl?

    Sure! []


  • by Xzzy ( 111297 ) <sether@tru 7 h .org> on Friday June 23, 2006 @08:29PM (#15593683) Homepage
    I know ImageMagik is the kitchen sink of image editing, but have you looked into PHP's embedded image functions? There's very few effects you couldn't produce on your own with those functions. I'll grant it's probably easier to just pass arguments to the ImageMagik library, but probably not more efficient.

    Allows you to avoid the problems of calling ImageMagik, piping it through perl, then doing whatever you need to do in PHP. Sounds like a recipie for excessive server load, to me.
    • Seriously, you're better off using temp files and the CLI for ImageMagick.
      • You'd probably be a LOT better off it you used Python and the Python Imaging Library [], instead of trying to noodle around with combining PHP/Perl/ImageMagick.

        First of all, PIL can solve your imaging problem, but more importantly, Python can solve your PHP problem. And then you won't have to get yourself hooked on a Perl problem as well.

        There is of course an ImageMagick module for Python []. But I prefer to use PIL, which is full featured, well integrated with Python, robust and efficient, and plays nicel

        • Almost any solution is better than mixing languages, but generally, it's best to use what's already configured (apparently PHP in this case), if time is a constraint.

          And yes, we know you have a favorite language. Most developers have one for interpreted and one for compiled (except those weird java guys who think they have the best of both worlds). I'm partial to C++ and perl myself. I could sit here and tout all the things that make me like it, but lets face it, most of the stuff I like about Perl, a Ru
  • ImageMagick? (Score:4, Informative)

    by martinultima ( 832468 ) <> on Friday June 23, 2006 @08:42PM (#15593747) Homepage Journal
    I tend to use ImageMagick a lot via PHP scripts, but not with any sort of polyglot of code or anything – I just use exec("convert ... ");. It's probably not the most cross-platform way, but since I tend to do exclusively Linux/UNIX-based stuff, and most of the code is only used by me for my own sites anyway, it's not a problem at least as far as I'm concerned.
  • by edremy ( 36408 ) on Friday June 23, 2006 @10:05PM (#15594118) Journal
    I am trying to write a question that will get the maximum number of snarky replies. Taco didn't post my "Advice for converting a Ruby on Rails application to ASP.NET?" submission, so do you have another suggestion?

    Thank you
    A. T. Roll

  • by Qbertino ( 265505 ) <> on Friday June 23, 2006 @10:21PM (#15594214)
    There's like ten bazillion ways to integrate PHP with Image processing tools like Image Magick just like with any other OSS language. Only more so because the PHP userbase is largest. No need to use some Hack involving Perl. Typo3 ( uses Image Processing to generate Menubuttons and stuff, there are countless other PHP projects out there doing the same, and it's no sweat at all to start the imagemagick CLI tools (contvert, etc.) including parameters from PHP. 30 lines of code max I'd say. Do you homework and then ask in some PHP forums and mailinglists for sample code. You'll get answers in no time.
  • This question isn't all that relevent to the topic other than a brief mention of PHP. No hard feelings if modded off-topic.

    I'm a 3D artist working in the VFX industry. Recently, I've been scripting within my 3D app. (The syntax of this language is a lot like PHP...) There are a lot of things you can do with the scripting portion of the app. You can write modeling plugins that play with the geometry. You can write shaders. You can automate tedious tasks. You can work on the RGB buffers after they've
    • Python can be something of a mind-trip if you've only used languages with a C-styled syntax such as PHP. The majority of the difference is in the lack of containing braces around blocks which is replaced by making whitespace meaningful. It works pretty well once you get used to it. Python is a terse language that doesn't make you spell out every little detail, such as Java or C/C++, and is strongly object oriented. I find Python easy to write and maintain for anything from a short script up to full-blown ap
    • Good languages are hard to design. Scriptable applications that dream up their own special-purpose scripting languages tend to have a lot of deep flaws and fundamental limitations. Most of the developer's resources go into the main application, not designing and supporting the scripting language. And special purposes non-standard languages usually don't have good development and debugging tools, either.

      Python is a very well designed language, with a huge active community and robust collection of tools a

  • by Anonymous Coward
    Congratulations! You found the worst of both worlds.
  • by joelwyland ( 984685 ) on Saturday June 24, 2006 @01:24AM (#15594896)
    Why do you need them to work in the same script? Have your PHP generate an img tag that references the perl script in the src attribute. Then the web browser will fetch the image data directly from the perl script and you don't need a Frankensteinian monster.
  • "Pearl and PHP DNA... just don't mix"
  • GD? (Score:2, Informative)

    May I ask why not GD? It's pretty mature and very usable in PHP. Most installations around the globe include GD2 so would it not be a more viable solution [especially if it's an open source project]?

    Just wondering. :-)

    • GD didn't support GIF files (legally) for a long time (you could always compile it in, but that meant nothing to people on shared hosting). Also, ImageMagick produced, in my opinion, better quality files at smaller sizes than GD used to.

      Of course, today, with no GIF problems and the quality on both about par, there's not a lot of difference.

      Our system offers a plugin based solution, use GD or ImageMagick with a single config file change. As far as calling ImageMagick from PHP goes, we just use the com

  • I've used both PHP and Perl for web development. I'd discourage mixing PHP and Perl in the same script, it's not necessary. Sure, it can be done, but just because it can be done doesn't necessarily make it a good idea. It will make your website harder to maintain, because whoever is going to maintain your website in the future will need to know both perl and PHP (granted, they are relatively similar languages).

    There is a clearly defined functional separation in this case, though. It would seem to me that yo
    • Okay, so slashdot doesn't properly replace brackets. That sentence ought to have been "There's nothing wrong with generating <img src=''> in PHP".
    • Using too many languages is bad?

      Hell, then a page of mine that uses all of:
      * bash
      * C
      * C++
      * Perl
      * perhaps even Python or some such (hell, I don't look under the pants of programs I call)
      * sed
      * grep

      And as far as I know, this is not a rare practice. If it's not a CPU-critical script, bash makes for good glue code. And you can't call it hard to maintain (at least until you look at sourceless configure scripts).
  • le-them-all/ []

    Embed all your languages, this file can be interpreted or compiled in 7 different coding languages:

    $ php
    #I'm a PHP script
    $ python
    I'm a Python program.
    $ perl
    I'm a Perl program.
    $ tclsh
    I'm a tcl script.
    $ sh
    I'm a sh script.

    Rename file to compile in C/C++:

    $ g
  • by Dalfiatach ( 984736 ) on Saturday June 24, 2006 @09:50AM (#15596001)
    So you've got Perl in your PHP, is there a way to do PHP in your Perl?

    I am in the joyous position of having to maintain a monstrosity of an application that was written by at least 4 different programmers over a period of years with numerous kludges plastered on top of a highly dodgy initial design.

    A lot of the early code was in Perl. Obfuscated, unreadable, indecipherable (and uncommented) Perl. So I decided to re-implement whole libraries of functions in PHP instead. But...a lot of what goes on in the application is driven by 2 Perl daemons, and they needed access to the new PHP libraries too.


    use LWP::UserAgent;
    my $ua = LWP::UserAgent->new;
    $ua->agent("PerlApplication/0.1 ");

    #construct the url (including GET params)
    my $varstring = "http://localhost/perlcalls.php";

    # Create a request
    my $req = HTTP::Request->new(POST => $varstring);
    $req->content_type('application/x-www-form-urlenco ded');

    # Pass request to the user agent and get a response back
    my $res = $ua->request($req);
    print "PHPresult: " . $res->content;
    # Check the outcome of the response
    if ($res->is_success) {

    #parse content of response
    if($res->content eq "OK"){
    print "PHP returned OK";

    else {
    #system failure, PHP unreachable
    print "PHP Failure!";

  • #!/bin/sh
    php <<EOF
    echo htmlspecialchars("Hello world!\n");

    perl <<EOF
    print "Hello world!\n";
  • Well you could use the PHthon PHP/Python bridge, then the Perlthon Python/Perl bridge.

    ...But what's the point of writing everything in one file but different languages? Why not write a pure PHP script that calls a pure Perl script directly? Or are you just looking for a way to avoid using more than one file, by making your application much more complex? Are they paying you by the hour, instead of for results, efficiency, simplicity, robustness, etc?

    Wasn't Parrot supposed to solve all these problems?

  • For your consideration: []

    If you would like to see a simple script which generates a graph on the fly, help yourself to this [].

    Yes, there are languages far more powerful than PHP. But, as I say EVERY TIME this flamewar goes down- are you sure you need them? As my grand-pappy used to say: why go deer hunting with a tank when a shotgun will do just fine?

Don't tell me how hard you work. Tell me how much you get done. -- James J. Ling