1

The CGI scripts and tools that comprise movabletype have the perl binary name hard-coded 

#!/usr/bin/perl -w

Unless I manually replace all these instances with

#!/usr/bin/env perl
use warnings;

it seems impossible to run movabletype under my private version of perl (installed with perlbrew). Is there some way I can run movabletype under the perlbrew perl without making these changes manually?

Gurunandan Bhat
  • 3,544
  • 3
  • 31
  • 43
  • 2
    Unless you're running the scripts with *my $app = Plack::App::WrapCGI->new(script => "/path/to/script.cgi", execute => 1)->to_app;* instead of *Plack::App::WrapCGI->new( script => "/path/to/script.cgi")* then starman isn't going to exec+fork to run the CGI script, so the Perl its going to run under is the same one Starman is running under, i.e. your perlbrew perl – MkV Jun 04 '13 at 07:18
  • 2
    Also *#!/usr/bin/env perl* is actually not sufficient to run your script under the appropriate perlbrewed perl, see https://github.com/Perl-Toolchain-Gang/ExtUtils-MakeMaker/issues/58 for more details. – MkV Jun 04 '13 at 07:21
  • MovableType does run the cgi script with execute => 1, which is why the system perl is being used. Thanks for pointing this out. – Gurunandan Bhat Jun 04 '13 at 13:46
  • 1
    @Ya.Perelman I started using Perlbrew sometime ago and I have no answer for this. I went through the MT instances installed on my localhost and changed the shebang lines rather than spend time on it. It's not a new problem, but that doesn't mean it shouldn't be raised to the MT development team. – Dave Aiello Jun 04 '13 at 15:03
  • @Dave After reading MkV's link above, I am inclined to believe that the MT Team would find a rock and a hard place on each side :). This is one of the times, an install script would have been handy.....So I just wrote one that goes recursively through the folders and replaces the shebang line with the correct location. perlbrew's "alias" command reduces the pain of doing this somewhat since I use a version cloned from github. The problem is not just with the cgi scripts but a whole lot of stuff in the tools folder as well as the minifying scripts called in the Makefile – Gurunandan Bhat Jun 04 '13 at 16:06
  • Running with execute => 1 seems to defeat the point of using starman at all (might as well use mod_cgi). Is MT CGI code so lax with use of lexicals that running it compiled in a sub will not work? Have you tried it with execute => 0? Running it with the CGI wrapper instead of with fork+exec is equivalent to running it under ModPerl::Registry. – MkV Jun 04 '13 at 16:32
  • MT under Plack runs applications in two ways. The first kind are of type "run_once" - essentially cgi apps like "MT-Upgrade" which are run with execute => 1. The second kind are run exactly as you mentioned - as compiled apps. For the first kind, the shebang matters. For the second kind the shebang does not and the perl version is the same as that under which Starman runs. Actually there is also a third type (XMLRPC), but I am running out of characters ;) Prompted by your comments I went through the sources and learnt how it all works. So thanks!! – Gurunandan Bhat Jun 04 '13 at 21:56

1 Answers1

0

... write a program to change them for you?

#! /usr/bin/env perl
use common::sense;
use Tie::File;

tie my @f, 'Tie::File', shift or die $!;
if ($f[0] =~ m,#! */usr/bin/perl( -w)?,) {
  $f[0] = '#! /usr/bin/env perl';
  splice @f, 1, 0, 'use warnings;' if $1
}
untie @f;

Somethin' like.

Julian Fondren
  • 5,459
  • 17
  • 29
  • Nice!! :) Thanks. Will wait to see if someone from the MT Team has a better solution – Gurunandan Bhat Jun 04 '13 at 05:50
  • 1
    *#!/usr/bin/env perl* is _wrong_ for perlbrewed perls, and starman is not going to fork+exec the cgi scripts, it will run them under the same perl as itself. – MkV Jun 04 '13 at 07:22
  • Thats what I would like to believe. Unfortunately, if you look at "System Info" link in the MT interface, it turns out it picks the system perl. Same with running mt-check.cgi under starman - it picks the system perl again. Could you elaborate why env perl is wrong for perlbrewed perls assuming env is located in /usr/bin? See http://perlbrew.pl/Dealing-with-shebangs.html – Gurunandan Bhat Jun 04 '13 at 10:01
  • Because you should be able to run a script installed for a perlbrewed perl that isn't currently in your PATH but it should use the correct perl. – MkV Jun 04 '13 at 16:23