（2024年リリースの Perl 5.40 まで対応しています） Perl5 は 2010年リリースの 5.12 以降、ほぼ毎年ペースでメジャーバージョンアップしています1。つまり 5.x の偶数 x が +2 されています。 Perl は後方互換性をとても重視した言語で、メジャーバージョンアップで過去の Perl プログラムが動かなくなることはほぼありません。また、バージョンアップによって変わる部分の多くが、速度的な改善であったり、限定的な状況におけるセキュリティ改善だったりといった、インターフェースにかかわらない部分です。 とはいえ、Perl も後方互換性を崩さないよう配慮した上で、実験的な機能として新しい組み込み関数や文法を追加することがあります。 そのときに活躍するのが feature プラグマ です。この記事ではそれら実験的な機能の登場バージョンをまとめました。 文字コード関連の

バージョンごとの表の絵文字は以下の意味です 使用可能 使用可能だが致命的な性能劣化を招くため忌避される （空欄） 対応前バージョン Perl 5.20 以降なら $& による方法が一番簡単ですが、それ以前のバージョンでの経緯を知っているチームメンバーから拒絶反応を受ける可能性もあります。そのプログラムが今後 Perl 5.20 より前のバージョンで実行する必要が一切ないと言えるなら $& でも問題ないと思いますが、外部公開するモジュールなどの場合は use v5.20 等で明言しないのであれば $& の使用は避けておくべきでしょう。 それぞれの手法 マッチ全体をキャプチャのカッコでくくって $1 で参照する方法 今も伝統的に行われている、マッチ全体をキャプチャのカッコでくくる方法です。 # $body から a か A で始まる単語を取り出して $match に入れる # \b は単語境界

Perl は C言語の文法を参考にしつつも、Bash シェルスクリプトで使われる sed や awk の置き換えも考慮したグルー言語でもあります。そういった複数の影響のためか、Perl とシェルスクリプトで似たような書き方なのに書き方が違うといった場合があります。 シェルスクリプトもシェルの数に応じた文法がありますが、ここでは Bash を取り上げます。 数値と文字、それぞれの比較演算子 Perl の場合は数値比較が == で、文字比較が eq Bash の場合は数値比較が -eq で、文字比較が = 細かい違いはあるにしろ、数値比較と文字比較が事実上逆の演算子になっています。 Bash では test としても知られる [...] と、後に導入された [[...]] の違いはありますが、今回は古くからお馴染みの [...] を取り上げます。 Perl はシェルスクリプトの文法を参考にして

Perl の真偽値はわかりづらいと言われます。 Perl とシェルスクリプトで逆になっていると思えるほど違う部分の理由を考える - Qiita この記事では以下のような考察をしました。 Perl の真偽値は、C言語のそれを踏襲したものになっていることはすぐにわかります。Perlにおける真偽値の複雑さというのは、C言語にはない文字列（C言語のようなchar型へのポインタといったものではなくプリミティブなもの）やリストや未定義状態といったものに対するPerlの考えといったものが入ったからだと思えます。元々のC言語が真偽値型を導入せず整数型（int型）で真偽値型を代用した功罪をPerlも受け継いでいるといえるのではないでしょうか。 もう少し考察していきましょう。 Perl における偽と評価される値 Perl には真偽値型（ブール型）といったものはありません。Perl での真偽の違いはわかりづらい

配列リファレンスやハッシュリファレンスは、「配列の配列」であったりといった多階層のデータ構造を作る上でよく用いられます。しかしながら、スカラーリファレンスについては一緒にその存在を教わるものの、その用途については解説されないことが多いです。 ここではスカラーリファレンスの用途を挙げていきたいと思います。この他にも用途を知っている方はコメントなどでフォローいただけると幸いです。 巨大なデータの受け渡し 以下のようなプログラムがあるとします。 my $str2 = greeting($str1); ... sub greeting { my $arg = shift; $arg =~ s/おはよう/おやすみ/g; ... return $arg; } greeting というサブルーチンに文字列変数 $str1 を渡して、何らかの処理をした後に結果を返すというもの。 ただ、greeting サ

先日「Perl のグローバル変数やレキシカル変数について - Qiita」という記事を書きました。 グローバル変数がパッケージと紐付いているという話までくると、型グロブといったリファレンス前夜の Perl 4 の時代に行われていたグローバル変数によるプログラミング手法まで話が広がるのですが、少々長くなりすぎることもあり、以前の記事はあの分量に収めました。 型グロブの詳解も含めた一般的な Perl のグローバル変数についてのお話はいつかするとして、グローバル変数という話で忘れられないのは sort 関数で使われる $a $b という変数です。この記事では sort 関数の基礎や $a と $b の正体を解明しつつ、sort 関数のような $a と $b を受け取って何かするブロックを伴うような関数を自作する方法を解説します。 sort 関数と $a と $b （※ sort のブロックについ

Perl にはいくつかの変数宣言があります。 my our local state my による変数宣言は多くの書籍で解説されていておなじみのものですが、それ以外の変数宣言の意味がイマイチわからないという声も聞きます。というわけで、ざっとまとめてみました。 use strict が無かった時代 モダンな Perl では、use strict を書いた上で、使用する変数は my を使って宣言をするということが常識となりました。 とはいえ太古の昔は use strict もなく、変数も宣言することなく使用していました。いわゆるグローバル変数だけの世界です。 まさに原始的なシェルスクリプトの世界に近いですが、今では好ましい書き方とはされません。スコープを狭めたり、初出の変数であることを明示したりといったことを my で行うことが好ましいとされています。Perl も例に漏れず、プログラミング言語で

こんにちは、mod_perlをこよなく愛用している @xtetsuji です。 みなさん、mod_perl使っていますか？Plack全盛の時代でも、まだレガシープロジェクトであったり、色々な理由でmod_perlを使い続けている方、結構いるんじゃないかと思っています。 「新しいものが良くて古いものが悪い」という考えは置いといて、mod_perlはとてもよく枯れていて実装も一つで安定したPerlの永続的実行環境の一つです。Plackやそれらのエコシステムを使えない現場では今も有力な選択肢の一つではないでしょうか。使用の際に極度にmod_perlにロックオンされないように設計すれば、中長期的な視野も入れた良いアプリケーションがかけると思います。 RHEL7ベータ発表 この記事を書いているのは2013年12月ですが、去る2013年12月11日にRHEL7のベータ版が登場しました。 RHEL 7、

Perlで use や require を使ってモジュールを読み込む場合、通常は @INC 配列に入っているパスのどこかに、所定の形式で配置されている必要があります。 具体的には、Foo::Bar というモジュールがあり、@INC 配列に /opt/lib/site_perl/ といったパス文字列があってそれが対象となる場合、/opt/lib/site_perl/Foo/Bar.pm というファイルとして存在している必要があります。 最終的には @INC をいじる必要があるのですが、現在のファイルの場所などを元にして、それをどう抽象化・簡略化するか、様々な手法があるようなのでまとめてみました。 モジュールが存在して読み込めるかどうかをワンライナーで確認する 例えば LWP::UserAgent モジュールが存在するかどうかを確認したい場合には以下のようにします。 存在すれば何も表示されませ

日本語リソースも充実しつつあるMojolicious。国内でもそうですが、世界的にもユーザ数が多いサービスではありますが、なかなか具体的な活用事例が出てきていない感じもします。 潜在的にMojoliciousの国内ユーザは多いと思うのですが、では困ったときにどこで聞けばいいのか、よくわからないユーザが多いと思いますので、私が知っている場所をいくつかご紹介します。 なお、私自身も英語が苦手なので、ここでは日本語で質問が出来る場所に限定しています。 各地のPerl Mongerの集まり「地域.pm」 Hachioji.pm などの Perl Monger の集まりに参加すると、その中に一人くらいはMojoliciousユーザがいることでしょう。そういう人に質問をぶつけてみると良いでしょう。 顔と顔を付き合わせて聴くことが出来る生の声は一番です。 主だった地域.pmを列挙しておきます。お近くの地

mod_perlってまだいけるの？ PlackベースのStarmanやStarlet、そしてMonocerosなどの優秀なウェブサーバ全盛時代、そしてApacheよりもNginxのほうが流行な昨今、Apache mod_perlが良い場合ってあるの？と聞かれることがあります。 mod_perl は今も開発が進められている とても安定している Apacheのノウハウがある技術者がそのノウハウを活用できる リバースプロキシをしたりしない分、 ミドルウェアとして起動されるデーモンが一種類減ることになり、ある種の案件では喜ばれる 場合がある mod_perl環境でMojoliciousアプリをデプロイする これは簡単な話で、MojoliciousはPSGI環境に対応しているので、Plack::Handler::Apache2 でデプロイしてやると良いです。 今回は Apache2.x と mod_

最近はMojoliciousも少しずつ使っています。@xtetsuji です 今回は、以前どこかの勉強会で質問に挙がったことを思い出して書いてみます。 Mojoliciousのビルトインサーバ2つ 先日の@yusukebeさんのアドベントカレンダーでは、plackupを使ってPSGIアプリとして起動する方法が解説されていましたが、Mojoliciousには最初から以下の2つのウェブサーバが同梱されています。 morbo (モーボと読むらしい) hypnotoad (ハイプノトードと読むらしい) この他にも、MojoliciousのMojo::Server::* 名前空間を見てみると、PSGIやらCGIやら、他の起動方法についてのサポートもあります。mojo help コマンドの出力も簡潔で参考になるでしょう。 morboとhypnotoadのプロセス起動方法の違い mojo generat

なので、ネット上ではPerlインタープリターに明示的に渡せないCGIで困っているケースが散見される。 "./script" などと「直接実行」した場合、まず実行しているOS環境(Linuxとか*BSDとか)が、それがスクリプトファイルなのか直接実行形式ファイルなのかを判別するが、前者の場合は1行目のshebang行が頼りになる。 ただ、Linuxなどの環境で改行コードとしてCR+LFを想定していない場合、shebang行がエディタでの見かけ上 #!/usr/bin/perl などとなっていても、それがCR+LF改行コードの場合には、LFが改行コードのOSにとってshebang行は となってしまい「"/usr/bin/perl<CR>" なんて存在しない」と言われることになる。これが bad interpreter の意味。 解決方法はエディタで改行コードをLFに変更すること。 一番上の実行