cmake で CGI (blosxom クローンぽいやつ) を書きました。(実用のためというわけではないです) https://github.com/blosxom-fanatics/blosxom.cmake/blob/master/blosxom.cmake.cgi cmake は -P をつけるとスクリプトモードになるので、それでふつうにCGIのコードを書くだけです。 データ型として文字列しかないのがつらい感じです。リストみたいなのも使えるけど、これもセミコロン区切りの文字列をリストとみなすという仕様になっている。シェルスクリプトのノリに近い。 ただ、正規表現がある程度使えるので、文字列操作は割と楽に書くことができる。 なお、cmakeで普通使うような命令を使わない（使えない）のでまったく通常ユースのためのノウハウはほとんど溜まらず、学習という意味ではあんまり意味がないというオチで
こんにちは、こんばんはおはようございます。nihenです。 自分のよく使っているモジュールであまり他で紹介されていないものって何かなーと探していたらCGI::Expandはあまり紹介されてないなと思ったので紹介します。 CGI::Expandという名前がついていますが、CGI.pmやCommonGatewayInterfaceとはそんなに関係がありません。 このモジュールの使いどころですが、httpのリクエストにおけるパラメータの受け渡しは key=value&key2=value といった、フラットなハッシュデータなわけです。ただしよく配列を表すのに key=value&key=value2&key=value3 といったデータで受け渡しを行うことがあります。こういったデータに対してしてCGI.pmの->paramはArrayRefを返すようになっていますし、Plack::Request
ApacheでのCGIの動作テスト 2006-11-02-1 [Tips][Programming] ApacheでCGIを動作させられない、と某氏がはまってた。 Apacheの設定を怪しんだが、結局はCGIスクリプトがエラー吐いてただけ。 いきなり複雑なCGIスクリプトでテストすると、設定が原因になのか スクリプトが原因なのかごちゃまぜになって分からなくなるので、 必ず動作する簡単なテスト用CGIスクリプトでまずは試そう！ 下記のようなテスト用スクリプトくらいはソラで書きたい。 「cat > test.cgi」して、打ち込んで Ctrl-D して、 「chmod a+x test.cgi」するだけ。 #!/usr/bin/perl print "Content-Type: text/plain\n\nHELLO\n";
Plack-0.9945 で任意の CGI スクリプトを実行可能になっていた件 http://search.cpan.org/~miyagawa/Plack-0.9945/ これまで Plack には Plack::App::CGIBin というモジュールが付属していたが、これは Perl script の実行しかサポートしていなかった。 しかし、Plack 0.9945 をつかと、任意の CGI script を実行可能となっている。 plackup -MPlack::App::CGIBin -e 'Plack::App::CGIBin->new(root => "./")->to_app' -p 9099 などとすると、 #!/usr/bin/python # -*- coding: utf-8 -*- print "Content-Type: text/plain" print pr
はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28
2010年5月12日(水) ■ /usr/bin/env じゃなきゃどうすんの? 大昔書いたことに対して、perl のパスをどう書き換えたらいいのかわからない CGI をただ使うだけのお客さんのために、#!/path/to/perl ではなく #!/usr/bin/env perl を使うという 反論をもらった。個人ベースで小さな CGI を作って配布する、というのは最近ではもうだいぶ廃れてきてるような気がしなくもないけど、まあ、4年も前も書いたことに対する話なんでそのへんは気にしないことにする。 envもその一環なの。否定するなら対案を示せといいたい。 _ こんなんどうでしょうか。 #!/bin/sh # -*- perl -*- # 動作には関係なし(エディタのモード判定用) PATH=/bin:/usr/bin:/usr/local/bin:... exec perl -x -opt
■ #!/usr/bin/env _ 今さらながら、 CGIの神話と現実というエントリ。ただし内容とはまったく関係なし。スクリプト言語の shebang 行（#!）でスクリプトインタープリタを直接書かずに /usr/bin/env でラップするという悪習はいったい誰が広めたんだろうか。ruby な人に多いように思うがそれだけじゃないし。 _ hoge というインタープリタを使うスクリプトの1行目をたとえば #!/usr/bin/env hoge としておくと、hoge の実行バイナリが /usr/bin/hoge でも /usr/local/bin/hoge でも $HOME/bin/hoge でもどこにあってもパスが通ってさえいれば起動できる。それはメリットなんだろうか。わしにはむしろデメリットにしか思えない。 _ /usr/bin/env を使うというのは、PATH の値にしたがってイ
CGIをPlackで開発(2) 前のエントリ書いたら宮川さんにオススメ方法を教えてもらった http://twitter.com/miyagawa/status/10271128928plackup \ -L Shotgun -MPlack::App::WrapCGI -e 'Plack::App::WrapCGI->new(script => "/path/to/cgiscript.cgi")' だそうです！これなら全ての要件を満たせるもよう！そしてapp.psgiを作る必要ありません。 今これやってみて一つだけ問題点。多分POD入りのCGIは動かない。それと、__DATA__は見てくれるけど、__END__があると動かない。__END__さっき簡単なパッチのpull requestを送っておきました！ カテゴリ 開発 タグ cgi perl plack 2
はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28
2009年06月23日15:30 カテゴリLightweight Languages perl - use CGI; use Encode; # 非英語Webプログラミング3原則 これは、実はPerlに限らず未だに事実だったりするのですが.... Perl でフォームデータから UTF-8 日本語文字をとりだす方法 (プログラミングの小石・大石) UTF-8 のフォームによっておくられたデータのなかから日本語文字をとりだすことは，日本の Perl CGI プログラマならたいてい必要になることである． ところが，その方法は意外に確立されていないようにみえる． しかし、元発言の方法は先祖帰りすぎるので。 Perlプログラマー以外にも、Webプログラマーであれば有用なentryです。 PerlでWebプログラミングする場合の三原則 QueryはCGIモジュールで処理する 文字コードはEncode
パーセントエンコーディング (英: percent-encoding) とは、URIにおいて使用できない文字を使う際に行われるエンコード（一種のエスケープ）の名称である。 「%」を使用していることから、この名称で呼ばれている。一般にURLエンコードとも称される。 URLエンコードには、上記のパーセントエンコーディングによる符号化と以下に記述するapplication/x-www-form-urlencodedによる符号化の2種類がある。半角スペースはパーセントエンコーディングでは「%20」に符号化されるが、application/x-www-form-urlencodedによる符号化では「+」に符号化される。 URL Standardでは、URLのパス部分の構文解析の際、以下 (path percent-encode set) に該当する文字であれば、UTF-8で符号化のうえパーセントエン
CGI.pmをベースとしたCGIアプリケーションを作成するためのフレームワークのCGI::Application::Dispatch。 ディスパッチ処理 http://example.com/app.cgi/index/ http://example.com/app.cgi/hoge/search/ など、URIによって処理を変える事ができる。 Perldocやnaoyaさんの記事などでは、http://example.com/app.cgi/モジュール名/run_mode名/などとすると良いそうです。 テンプレートの対応 HTML::Template,プラグインでTT(Template-Toolkit)にも対応しています。 プラグインも多様 CGI::Application/plugin/*が豊富にあり、フォーム作成などを助けてくれるモジュールなど。 プラグインの参考ページ http:/
Blog Search when-present<#else>when-missing. (These only cover the last step of the expression; to cover the whole expression, use parenthesis: (myOptionalVar.foo)!myDefault, (myOptionalVar.foo)?? ---- ---- FTL stack trace ("~" means nesting-related): - Failed at: ${entry.path} [in template "__entry.ftlh" at line 3, column 25] - Reached through: #include "__entry.ftlh" [in template "entry.ftlh" at
重要なデータファイルは、外部から閲覧できるディレクトリに格納すべきではない。外部から閲覧できないディレクトリにしておけば、httpd.confにわざわざ指定する必要もないのだ。 見られて困るデータファイルは、公開ディレクトリに配置して非公開に設定するのではなく、非公開ディレクトリに配置するべきだというお話。 ……で、この話で思い出したことが。 以前、社内で「cgi-binはドキュメントルートの外に置いてScriptAliasにするべきだ」という意見に対し、「cgi-binは普通のディレクトリにExecCGIでも良いのではないか」という意見が出て議論になったことがあります。 ScriptAlias派の意見としては、こういうことです。 データファイルをcgi-binに置くべきではないが、うっかり置いても大丈夫な状態の方が良いのではないか。それに対し、ExecCGI派の意見はこうなのですね。 デ
URLデコード処理とは、CGIで標準入力からHTMLフォームデータを読み込む時の定石の処理です。 @pairs = split(/&/,$buffer); foreach $pair (@pairs) { ($name, $value) = split(/=/, $pair); $value =~ tr/+/ /; $value =~ s/%([a-fA-F0-9][a-fA-F0-9])/pack("C", hex($1))/eg; $FORM{$name} = $value; } $buffer変数内では、『要素名1=データ1&要素名2=データ2&..要素名N=データN』のデータ並びを想定します。 これは、CGIでHTMLのフォームデータを標準入力から読み込んだデータ並びです。 これを、『&』デリミタでsplitし、『要素名=データ』毎の配列『@pairs』を作成し、 つぎに、『@pa
先日、奥さんの要望によりCache::AdaptiveをCGI::Applicationで使いやすくするプラグインを書きました。 現在はversion 0.03でCPANにCGI::Application::Plugin::Cache::Adaptiveとしてアップされています。 Cache::Adaptive自体については、CPANのドキュメントないしは、奥さんの下記の関連エントリをご覧下さい。 負荷に応じてキャッシュを自動調節する Perl モジュール Cache::Adaptive の使い方 Cache::Adaptiveを簡単に使う方法 使い方や実装方法について簡単に説明してみようと思います。 すぐ分かる使い方 実際はやる事は二つしかありません。 CGI::Applicationを継承したクラス内でcache_adaptive()メソッドを使ってCache::Adaptiveまたは
この他に、日本語の情報としては、川合さんの河馬屋二千年堂でCGI::Applicationモジュール v.1.2 の和訳ドキュメントを見ることができます。上記の4.04版のドキュメント和訳にあたっても、参考にさせていただきました。 CGI::ApplicationモジュールのSYNOPSISにあるサンプルでは、CGIファイルとモジュールを"webapp.cgi"と"WebApp?.pm"の2ファイルに分けています。 実際のアプリケーション作りではこうなっていたほうが（再利用性や柔軟性などから）良いと思いますが、ちょっとCGI::Applicationを試してみるなどという時には、ライブラリパスなどを考えなくて済むように、1ファイルにまとめたいと思うこともあります。この時は、単純に次のようにするだけで実現できます。 !#/usr/bin/perl ### 元"webapp.cgi"の内容..
NAME SYNOPSIS INTRODUCTION USAGE EXAMPLE ABSTRACT DESCRIPTION Instance Script Methods Sub-classing and Override Methods Application Module Methods Testing PLUG-INS Existing plug-ins Writing Plug-ins Writing Advanced Plug-ins - Using callbacks COMMUNITY SEE ALSO AUTHOR CREDITS LICENSE DOCUMENT TRANSLATION Page Top NAME CGI::Application - 再利用可能なWEBアプリケーションを構築するためのフレームワーク Page Top SYNOPSIS # "WebApp
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
