path設定のセパレータがOSで違うのにハマった

ちょっと複雑な設計になってくると、パスの制限を回避したくなります。
いや、本当はそういう制限があっても問題ないのが本当はいいのだけど、いちいちdefineで宣言するのもめんどくさいし、過程よりも結果に重きをおくべきなのはいうまでもありません。
ということで、set_include_pathをいじって、システムの設計を一部変更して、テストサーバにアップしたとたんに異変が。
今まで動いていたのが、ファイルが見つからないの嵐に。
よくよく調べたら、Windowsとそれ以外ではpath設定のセパレータが異なるという。
OSのpathを利用しているからだと分かればたいしたことないのだけれど、コロンとセミコロンなんて、ぱっと見て違いに気づきませんよ、普通。
定数のPATH_SEPARATORを使えばいいのだけれど、こういう回避の仕方はphpだからこそというか、無理やりというか・・・
マニュアルのページには以下のようなコードが載っていました。

<?php
if ( ! defined( "PATH_SEPARATOR" ) ) {
  if ( strpos( $_ENV[ "OS" ], "Win" ) !== false )
    define( "PATH_SEPARATOR", ";" );
  else define( "PATH_SEPARATOR", ":" );
}
?>

phpの定数とか関数の初期値は、バージョンが変われば変化してしまう危険があるので、あまり使いたくないけど、どの道php6はまだ先のことだろうから、とりあえずPATH_SEPARATORをつかってしのぐことにしようかな。

.htaccessでやればいいみたいだけど、詳しい説明が載ってない。
設定済みのものを取得私鉄かしたいような場合だと、.htaccessでは全部書き直さなければいけないようなので、phpで一度取得した後に再設定する方法がいいのだろう・・・。

と、散々愚痴っていたけど、php.iniをよく見たら

; UNIX: "/path1:/path2"
; Windows: "\path1;\path2"


このように、しっかり書かれてあった。

まとめると、以下のようになる
php.iniで設定する場合

include_path = ".;c:\php\pear;c:\php\cli\pear;c:\home\php_myLib"

.htaccessで設定
する場合

php_value include_path ".:/usr/local/lib/php:/home/user/php_myLib"

長いこと使っていても知らなかった。
というか、使うことがなかっただけかもしれない。

PHPでメールを送信するときのメモ

メール送信はどうも使い慣れません。
現在のWebコンテンツでメール送信は切っても切り離せないものですが、どうも使い方に慣れません。

とりあえず、何度かこうやってメモしていけば体が覚えてくれることでしょう。
本棚にはオライリーの4000円もする「電子メールプロトコル」の本がありますが、たいして活用されていません。

とりあえず、さて、メールを送信したアドレスが存在しない場合、その送信先のドメインが存在しなかったり、ユーザが存在以内場合はリターンメールが返ってくるのですが、その通知先を指定できます。
(そもそもこの考え方であっているのか?)
ヘッダでは「Return-Path」です。
ヘッダにあたる部分には以下のように記述しておくことになっています。

Return-Path: return@exsample.com


しかし、この方法ではほとんど有効ではなく、スクリプトやサーバが指定したものに強制的に上書きされることがほとんどのようです。
もちろん、設定できるのですが、動的に変化させる場合この方法では使えません。
これを回避するには、sendmailへのスイッチが有効なようです。
PHPでは第5引数に次の内容を追加します。

"-f return@exsample.com"


つまり実際にはこうなります。

mb_send_mail( $to, $subject, $body, $headers, "-f $mail" );

これで、受信したメールのソースを見ても正常に設定されました。

メール送信用のモジュールやライブラリを使っている場合はこの限りではありませんので、ご注意ください。

参考にしたのはこのあたり
http://builder.japan.zdnet.com/member/u87200/blog/2009/02/08/entry_27020134/

PHPのHTTP_Clientライブラリ

ファイルをアップロードするにはHTTP_Clientがいいらしいんだけど、
セッションでログイン管理しているからCookieを食わせなくてはいけない。
正確には、すでに食っているので、クッキーの値を送ってやる必要がある。
いろいろ調べてみると、HTTP_Client_CookiManagerというものがあって、passCookies()でセットできるらしいところまではわかったけどうまくいかない。
解説サイトも翻訳しただけで、ろくなサイトが見つからない。
やっぱりこういうクライアント側のごにょごにょはPerlしか使い物にならないのだろうか・・・

イラレと同じ大きさの画像を作る

ImageMagickでEPSを背景なしのpngにする方法があったけど、やり方をすっかり忘れてしまったので、GostScriptにお願いすることに。

・イラストレータで見た大きさと同じ画像に変換するには「-r72」のおまじない
・背景を透明にするには「-sDEVICE=pngalpha」のおまじない

を唱えよう

gs -q -dSAFER -dNOPAUSE -dBATCH -sDEVICE=pngalpha -dEPSCrop -r72 -dTextAlphaBits=4 -dGraphicsAlphaBits=4 -sOutputFile=output.png input.eps

Windowsの場合はgsではなくgswin32cになります。

モジュールがmod_perlに対応しているかどうかについて

mod_perlでいろいろ動かしてみると、モジュールの対応というものを意識せざるを得なくなりました。
自作のテンプレートモジュールをテストしていたところ、どうも通常とは結果が異なることに気がつきました。
よくよく調べてみると、モジュール内で保持している変数の値がずっと残っているためと判明。
newで呼ばれるところに初期化の処理を加えたところ、希望通りの動きをしてくれました。
よくよく考えると当たり前なのですが、作りが甘いことを実感しました。
公開中のものも、そのうち修正しないとダメですね。

CentOS5.2でmod_perlを使えるようにする

かなり昔(確かApache2.0が出た頃)にWindows2000でmod_perlを使ってみようとして挫折したままでした。
なぜ動かなかったのかまでは、はっきり覚えていません。
心機一転、改めてmod_perlに挑戦です。
OSはCentOS5.2、Apacheは2.2.3、mod_perlは2.0.2です。

まずは、mod_perlをインストールします。

yum -y install mod_perl


パッケージが見つかるとインストールが開始され・・・ずに、

Parsing package install arguments
Package mod_perl - 2.0.2-6.3.el5.i386 id already installed.


つまり、既にインストールされているとのこと。
手間が省けてラッキーなのか、必要のないモジュールをロードしていたのは問題なのかは気にしてはいけません。
次に、httpd.confを設定しますが、この環境ではperl.confから設定をロードしているので、そのファイルの編集します。

LoadModule perl_module modules/mod_perl.so


これは先述の通り、インストール済みでロード済みなので、このまま。
仮にコメントアウトされているなら外します。
次に、スクリプトの起動設定ですが、perl.confで弄ると、なぜか500エラーになってしまうので、.htaccessで設定を行うことにします。本当はエラーの原因を見つけ出して修正できればいいのですが、まだまだ勉強が必要のようです。
httpdをrestartして問題がなければ、.htaccessの設定に移りましょう。

# mod_perl
<IfModule mod_perl.c>
  <Files ~ "\.(cgi|pl)$">
      SetHandler perl-script
      PerlHandler ModPerl::Registry
      PerlSendHeader On
  </Files>
</IfModule>


そもそも、拡張子の.cgiと.plはAddHandler cgi-scriptで設定してあるので必要ないのかもしれませんが、一応付けておきます。
mod_perlが実行できるかどうかは、

#!/usr/bin/perl -w
use strict;
print "Content-Type: text/html\n\n";
print exists $ENV{'MOD_PERL'} ? 'true' : 'false';


このようなスクリプトで確認できます。
trueが表示されれば、サーバー側の設定は終わりました。

次はスクリプトの設定です。
基本的な事として、編集の初期化に注意すること、実行パスはルートになることさえわかっていれば、特に問題はないでしょう。
自作のモジュールなどを利用している場合は、モジュールを読む前に、例えばドキュメントルートが/home/public_html/の場合は、

use lib '/home/public_html/';


ちなみに、BEGINではダメらしいです。
そして、

chdir '/home/public_html/';


このあたりを押さえておけば動くはずです。

Let’s mod_perl life!

Windowsではどうやるんだろう・・・orz

XML::libXMLで文字コードが化ける

PerlのXML::libXMLモジュールのお話です。
問題が発生したのと同じ条件で、例題として、xmlの中のNameを取り出すことにする。

my $parser = XML::LibXML -> new();
my $dom = $parser -> parse_file( $file );
my @xmlObj = $dom -> getElementsByTagName( 'xml' );
foreach( @xmlObj ){
	my $name = $_ -> findnodes( './Name' );
}


$nameに入る文字がUTF-8のとき(スカラーではなくリファレンスが入る?)、UTF-7に化けることがあるらしい。
どうしてこうなるのかは謎。
パースの問題なのか、どこかでコードを指定しなければならないのかはよく分からず。

Operation “eq”: no method found,

Perlでエラーのお話。

“eq”は別の予約語の場合もあり。
例えば、

if( $temp eq 'asdf' ){}


という、何の変哲も無い比較を行うときに出現するエラー。
これを回避するには、

if( "$temp" eq 'asdf' ){}


とすればいいのだけれど、これは$tempが純粋なスカラーでない場合に発生する。
つまり、

print ref $temp;


この場合、リファレンスを調べるとSCALARではないとき。
自分がよく遭遇するのは、

XML::LibXML::NodeList


のとき。
スカラーが帰っていると思い込んでいると、たまに痛い目にあいます。