Yearly Archives: 2013

SQLite Integration 1.5 リリース

English version is available in SQLite Integration 1.5 released

SQLite Integrationを 1.5 をリリースしました。

  1. WordPress3.8 でのインストールと動作テストをしました。
  2. 新しく採用された管理画面に合うようにユーティリティのスタイルシートを変更しました。
  3. SQLite のコンパイルオプションを調べて、LIMIT 句つきの UPDATE や DELETE ができるかどうかをチェックするようにしました。
  4. SQLite と MySQL を切り替えて使えるオプションを追加しました。

前のバージョンでも WordPress3.8 が正常にインストールできることを報告してくれた方もいらっしゃいますが(ありがとうございます)、自分でもチェックしてみました。インストール、アップグレードともに問題がないようです。

ついでに、Subversion リポジトリの 3.9 アルファバージョンもチェックアウトしてみました。どうやら、mysqli や PDO ライブラリの採用はまだないようです。PHP 5.5 でも Notice が出ないように、E_DEPRECATED を抑制して、mysql ライブラリを継続して使っています。次期バージョンでも根本的な変更なしで、SQLite Integration が使える見込みです。

WordPress3.8 では、管理画面が新たなレスポンシブデザインに変更になりました。個別にプラグインとして開発されていた MP6 の成果が取り込まれているのです。モバイルデバイスでこんなところは見ないだろうと思いますが、スタイルシートを変更して、できるだけデザインを合わせました。ユーザのプロファイルページで、8つのカラーテーマが選択できるようになっていますので、選択されたものと同じ色を使うようにしました。あまりやる気がないので、やっつけだというのがバレバレだと思います。 🙂

新たなバージョンでは、SQLite ライブラリが、’ENABLE_UPDATE_DELETE_LIMIT’オプション付きでコンパイルされているかどうかをチェックするようにしました。このオプション付きなら、クエリの書き換えをせずに直接データベースに渡します。プラグインフォーラムを読んでいると、PHP 5.4 や 5.5 に移行した人が増えてきているようなので、SQLite ライブラリも変更になる可能性があり、複数行の values 句や、LIMIT をともなった UPDATE や DELETE 文が使えるようになっているかもしれないからです。もし、そうなら、データベース操作がより安全に、また、より速くなるはずです。

wp-config.php で、MySQL に簡単に切り替える方法はないか、という naillik 氏のコメントで、確かにそういう使い方もあるなぁ、と納得したので、それができるようにしました。新バージョンでは、wp-config.php で次のように定数を定義すれば、SQLite Integration の機能を停止できます。

"true"を"false"にするか、行を削除すると、SQLite に戻ります。最初に切り替えたときには、WordPress のインストーラが走るはずですから、通常どおりインストール作業をしてください。ただし、それぞれでの環境は引き継がれませんので注意してください。また、SQLite 用パッチをあてたプラグインを使っている場合、SQLite Integration が読み込まれていないと動かないものがあります。例によって動作保証はしませんので、好きなようにお使いください。

いくつかのファイルで、WordPress から呼ばれたかどうかをチェックするようにしました。実際には、外部から直接呼ばれても、サイトに害を与える動作はできません。が、サイトへの攻撃をする人たちは、脆弱性ありの(存在しない)プラグインのディレクトリや、脆弱性ありの(存在しない)phpファイルへのアクセスを繰り返します。このサイトも例外ではなくて、ありもしないファイルへの不正な GET や POST アクセスが毎日あります。パスカルの蠅のようにうんざりですが、蠅に蠅取り壺からの出口を示すこと(L. ヴィトゲンシュタイン)くらいのことはしておくことにしました。

Alex Almeda 氏のご協力に感謝します。プラグインに関するヒントを与えられました。

不具合やバグを発見したら、このサイトでコメントしていただいても、サポートフォーラムに投稿していただいてもかまいません。提案や感想も歓迎です。ありがとうございました。

SQLite Integration 1.5 released

Japanese version is available in SQLite Integration 1.5 リリース

SQLite Integration version 1.5 was released.

  1. WordPress3.8 installation and compatibility are tested.
  2. Changed the admin panel style sheet to fit the new responsive Admin panel.
  3. Added the code to check if the SQLite’s compile option about UPDATE or DELETE with LIMIT is enabled or not.
  4. Added the functionality to change the database between SQLite and MySQL.

Some of the users reported that they succeeded in installing WordPress3.8 with an older version (thanks for reporting), I checked myself if the latest version of WordPress works fine. I found no problems about installing or upgrading.

And I also checked out the 3.9 alpha version from the subversion repository. The alpha version doesn’t use PHP mysqli library nor PDO library but still use mysql library with the suppressing of E_DEPRECATED error reporting. This means that the next version of WordPress will continue to use the same database access method and you can use SQLite Integration without radical changes.

Admin panel of WordPress3.8 is changed to a new responsive design. It has included the former MP6 plugin developed separately. I don’t know if users want to see their database status with a mobile device or not, but I changed the style sheet to fit for it as much as I could. You can also select one of the eight color schemes on your profile panel. I add some stylesheet to use the same color that you select, though a little reluctantly. 🙂

The new version of the plugin checks if your SQLite library is compiled with the option ‘ENABLE_UPDATE_DELETE_LIMIT’. If it is, the plugin will not rewrite the UPDATE or DELETE with LIMIT query. Seeing the WordPress plugin forum, there’re more and more bloggers come to use PHP 5.4 or 5.5, which means their SQLite library is upgraded and the plugin has more chances to be able to use multiple values clause and UPDATE or DELETE with LIMIT clause. If this is the case, the database manipulation will be a little safer and faster.

I’ve got the comment from Mr/Ms naillik who wants to change the database with the directive in wp-config.php. I included this functionality in the current version of the plugin. If you want to use MySQL, add the next line in your wp-config.php (of course with correct MySQL settings).

This enables you to change the database from SQLite to MySQL. WordPress installation process will run for the first time, so you’ve got to install with MySQL. But notice that the post data or other environments settings are not migrated from one database to another. And most of the patched plugins require SQLite Integration. If you want to use SQLite again, change "true" to "false" or just delete that line. Try if you like, though I give no warranty at all as usual.

I added a few lines for some of the files to check if they are called from WordPress or not. In fact, even if they are called outside your site, they can do nothing to harm your site. But crackers are accessing the vulnerable (nonexistent) plugins’ directory, targeting the vulnerable (nonexistent) php files. This site is not an exception and has illegal GET or POST access every day. It’s really annoying like a Pascal’s fly. This is only to "shew the fly the way out of the fly-bottle"(L. Wittgenstein).

I’d like to express my thanks for Mr. Alex Almeda, who has given me some hints about the plugin.

When you notice malfunctioning or bug, I’ll appreciate receiving your reports or suggestions by the comment in this site or posting to the support forum. Thank you.

Python2.7 と Python3.3 を Windows で併用する

English version is not available.

Rilchiam! (Python2.x vs Python3.x)

Under which king, Bezonian? Speak or die!
——William Shakespeare, The Second Part of King Henry the Fourth
どの王様のことかな? 悪党め。言ってみろ、さもなきゃ、殺しちまうぞ。
——シェイクスピア, 『ヘンリー四世・第二部』

Python 2.x と 3.x のどちらを優先して学ぶのがいいのでしょう? これから Python を勉強しようという、私のような初心者にとって、これが問題になるのは、比較的新しい教本を読むと(*1)、3.x を中心として書かれているものが多いように感じますが、Google App Engine は 3.x に対応していなくて、Git をコンパイルしようと思ったら、Python 3.x ではエラーで止まり、レンタルサーバにインストールされている Python も 2.7 しかなくて、これでは実際に 3.x を使うチャンスなどないのではないか、という懸念があるからです。教本をざっと読んだ限りでは、後方互換性が一部損なわれているといっても、言語の構造については根本的な変更が加えられているわけではないので、2.x を学んで 3.x での変更点を学び直すのは(あるいは、その逆でも同じだけれど)、未知の外国語を勉強するほどの苦労はいらないだろうと思います。現代的なプログラミング言語は、ライブラリ(モジュール)が巨大になってきていて、言語のシンタックスを学んだだけでは何も作れないのが現実ですから、本当の勉強は、実は、シンタックスを学んだ後に始まります。Eclipse や Visual Studio といった開発環境は、Java Doc や、MSDN を簡単に参照できるようになっていますが、補完機能だけでは、未知のライブラリ関数については無力なので、ドキュメントの参照機能が必須だからでしょう。今から振り返ると、Unix のマニュアルページは、シンプルなだけに、よくできていました。

とはいえ、実際に Python 2.x 用のスクリプトを 3.x で動かしてみると、print 文や例外処理の変更だけではすまないエラーに遭遇するのも事実です。そうなると、両方を手元に置いておいて、動かしてみて違いを比べたいというのも人情でしょう。私自身、Debian には Python2.7 と 3.2 を、Windows には Python3.3 をインストールして使い分けていましたが、いちいちターミナルエミュレータで Debian マシンにログインするのが煩わしくなって、結局、Windows マシンに両方をインストールすることになりました。

たとえば、これが Debian GNU/Linux ならば、普通に両者をインストールして、update-alternatives コマンドで、どちらかをマスタに設定すれば併用に不自由はありません。でも、Windows では、どうすればよいのでしょうか。公式のドキュメント(最新日本語ドキュメントPython 2.7ja1 documentationおよびPython 3.3 documentation(翻訳中)(*2))は、Python 2.x 用と Python 3.x 用とが分かれていて、Python 2.x の方には、同じマシンに複数のバージョンをインストールする場合の注意がありません。これにはわけがあって、Python 3.3 をインストールすると、素晴らしく便利なユーティリティが付属していて(後述)、シェルに cmd.exe を使う限り、パスを通すくらいで、他にはほとんど何もしなくてもちゃんと使えるようになっているからです。

以下はその設定例と考え方ですが、MinGW の mintty を使っていたりするので、cmd.exe よりは少し面倒なことになっていますが、基本は共通です(*3)

  1. *1 O’Reillyの"Learning Python"第3版(2007年)で使われているコード例は Python 2.5 ベースで、3.0 でそのまま動かすとエラーになる部分を含んでいましたが、第4版(2009年)になると、3.0 を前提としたコードになって、2.6 では動かない部分について注釈を加えるというスタイルに変わりました。また、同じ著者による"Programming Python"第4版(2010年)では、"Python 2.X is no longer supported here(Python 2.x はもうサポートしない)"と言われています。
  2. 後に述べる py.exe のパートに入る直前まで翻訳されています。
  3. MinGW の mintty については別の投稿で書きましたので参考にしてください。

インストール

インストーラの指示に従ってインストールしてください。途中のオプション選択で、「Register Extension」のチェックを外しておけば、どちらを先にインストールしてもかまいません。

Windows 環境へのインストールについては、

が、基本的な情報を提供してくれます。また、公式ドキュメントからたどると、モジュールのインストール方法やインストール場所、その設定方法なども知ることができます。Windows の場合、インストール自体で困ることはないでしょう。ただ、オプション設定で、「Register Extension」を選択したかどうかによって、.py 拡張子と実行ファイルの関連付けが異なります。オプションにチェックした状態でインストールすると、.py 拡張子のファイルをダブルクリックしたときに、後にインストールした Python が起動するようになります。

もし、「Register Extension」をチェックしたいのであれば、後に述べる理由によてって、先に Python 2.x を、次に Python 3.x をインストールする方が、使い分けが断然楽になります。

IDLE を使ったり、python.exe を直接ダブルクリックするのではなく、シェルから python を起動する場合は、%PATH%環境変数で与えられたパスから python.exe が検索されます。ドキュメントに従って、%PATH% を設定しておきましょう。コマンドプロンプトや他のシェルで、python と打った時に起動してほしい方を先にします。ドキュメントでは、「autoexec.bat ファイル」と書かれたりしていますが、「コントロールパネル -> システムとセキュリティ -> システム -> システムの詳細設定」とたどって、「環境変数」を設定しましょう。

または、

となります。

インストール後の環境

さて、実行ファイルへのパスが通った状態を確認しておきましょう。%PATH% では、C:\Python27 が先にある設定です。

Python2.7.5 の場合(事情があって、32bit 版をインストールしてあります)。コマンドプロンプトで、python と入力して実行すると、下のようになります。

> python
Python 2.7.5 (default, May 15 2013, 22:43:36) [MSC v. 1500 32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import sys
>>> sys.path
['', 'c:\\Python27\\python27.zip', 'c:\\Python27\\DLLs', 'c:\\Python27\\lib', 'c:\\Python27\\lib\\plate-win', 'c:\\Python27\\lib\\lib-tk', 'c:\\Python27', 'c:\\Python27\\lib\\site-packages']
>>> sys.prefix
'C:\\Python27'
>>>

Python3.3.2 の場合は、フルパスを与える必要があります。

> C:\Python33\python
Python 3.3.2 (v3.3.2:d047928ae3f6, May 16 2013, 00:06:53) [MSC v. 1600 64bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import sys
>>> sys.path
['', 'c:\\Python33\\python33.zip', 'c:\\Python33\\DLLs', 'c:\\Python33\\lib', 'c:\\Python33', 'c:\\Python33\\lib\\site-packages']
>>> sys.prefix
'C:\\Python33'
>>>

モジュールの検索は、sys.path に登録されたパスから探すことになっていますが、デフォルトのサーチパスがすでに設定されています。ドキュメントによると、デフォルトのサーチパス(たぶん、prefix から後の相対パス)は、ビルド時に設定されているということです。ドキュメントでは、この sys.path の値がどのように作られるかが説明されています。まとめると次のようになるようです。

  1. カレントディレクトリを自動的に登録する。最初の空文字列”がこれです。
  2. 環境変数PYTHONPATHがあれば、そこに指定されたディレクトリを登録する。
  3. レジストリにPythonPathエントリがあれば、そこで指定されたディレクトリを登録する。
  4. 環境変数PYTHONHOMEが設定されていれば、そこから、なければ、python.exeのあるディレクトリから、Lib\os.pyを特定し、PYTHONHOMEを推定して、必要なサブディレクトリをsys.pathに登録する。
  5. PYTHONHOMEもPYTHONPATHも特定できず、レジストリのエントリもない場合は、デフォルトの相対パスが使われる。
  6. モジュール検索パスに、拡張子 .pth のファイルがあれば、そこに書かれたパス(相対パスでも絶対パスでもよい)を、sys.path の最後に付け加える。

「レジストリの PythonPath エントリは常に読み込まれる」とのことです。実は、インストールオプションで「Register Extension」を外しておいても、Python のインストーラは、レジストリに PythonPath などの値を書込みます。その他、インストールフォルダの記録や、アンインストール時に使う情報なども書き込まれます。

調べてみると、HKEY_USERS と HKEY_CURRENT_USER に、それぞれ PythonPath のエントリがありました。

キー \HKEY_CURRENT_USER\Environment\Software\Python\PythonCore\2.7\PythonPath
設定値 C:\Python27\Lib;C:\Python27\DLLs;C:\Python27\Lib\lib-tk
キー \HKEY_CURRENT_USER\Environment\Software\Python\PythonCore\3.3\PythonPath
設定値 C:\Python33\Lib;C:\Python33\DLLs

これらの値とデフォルトの値が、それぞれの Python 起動時に読み込まれているということですね。

これを見ると、環境変数に、%PYTHONHOME% や %PYTHONPATH% があらためて設定されていなくても、実行ファイルが起動できれば、何の問題もなさそうです。

使い分け

上に書いたように %PATH% の設定がされていれば、Python2.7 は、通常どおり、python コマンドで起動できますから、Python3.3 をフルパスではなくて、起動することだけを考えればよさそうです。ところが、Windows のコマンドプロンプトなら、それでいいのですが、MinGW の mintty を使っていると、対話プロンプトが表示できません。仕様というか、使っている人はだれでも知っていることなのですが、まあそういうことになっているわけです。-i オプションをつけて起動すればよいのですが、オプションなしで起動しても、対話プロンプトになってほしいので、これが実現できるように、mintty の設定を後で例示します。

幸い、Python3.3 には、py.exe、pyw.exe という素敵なランチャが付属しているので、これを使って、起動を制御することにします。Python 3.x をインストールするときに、「Register Extension」をチェックしておくと、.py ファイルは py.exe と、.pyw ファイルは pyw.exe と関連付けがされるようになります。現在の実行ファイルの配置は次のようになっています。

C:\Python27\python.exe
C:\Python27\pythonw.exe
C:\Python33\python.exe
C:\Python33\pythonw.exe
C:\Python33\py.exe
C:\Python33\pyw.exe

cmd.exe を使う場合

Windows のコマンドプロンプトを使っての起動方法は以下のようになっています。

> python(w)             -> python2.7が起動する
> py(w) (-2)            -> python2.7が起動する
> py(w) -3              -> python3.3が起動する
> C:\Python33\python(w) -> python3.3が起動する

ほとんどこれで十分なのですが、「"py -3"でも長すぎる! 俺は"p3"で、python 3.3 を起動したいんだ」という場合は、C:\Python33 ディレクトリに、下のような p3.bat みたいなファイルを作っておけばお望みの動作ができます。

これで、下のように起動できます。

> p3

でも、こんな面倒なことをするよりは、py.exe という素敵なランチャを使うようにしましょう。

py.exe というランチャ

この py.exe というコマンドは、What’s New In Python 3.3Using Python on Windows に記述がありますが(日本語訳はWindows で Python を使うですが、ちょうど py.exe の説明から未訳となっています)、なかなかすぐれもので、バージョンを選ばずにどの Python でも起動できます。32bit、64bit も関係ありません。コマンドラインから起動するときは、上に書いたように、オプションをつけると、そのバージョンが起動できるのですが、メジャーバージョンだけでなく、マイナーバージョンまで指定できます。32bit 版と 64bit 版がインストールされていると、64bit 版が優先されますが、オプションに -32 をつけると、32bit バージョンが起動できます。

> py -2.5-32

として、起動すると、ちゃんと Python2.5 の 32bit バージョンを呼べるとのことですから、2.x を複数、3.x を複数インストールしてあっても使い分けができます。オプションなしで、起動すると、"the most recent version is used by default"(最も最近のバージョンがデフォルトで使われる)とのことですが、これは、新しいバージョンのほうが後にインストールされているはず、という前提のようで、必ずしもバージョン番号が大きいということではなくて、一番最後にインストールしたバージョンという意味のようです。

実は、インストール時に .py ファイルの関連付けをするように指定すると、この py.exe コマンドに割り当てられます。.pyw は、pyw.exe に割り当てられます。

このランチャがすごいのは、上のようにコマンドラインからオプションで起動を制御できるだけでなく、Python のソースファイルの先頭に shebang 行があると、それを読んで Python のバージョンを決定したり、設定ファイルや環境変数で制御したり、ということができるのです。ポータビリティがよくなり、Windows をあまり意識せずにプログラミングができるかもしれません。ただし、後で述べるように、Apache とともに、CGI として使うときには、環境が引き継がれないので、制限があります。

順番に見ていきましょう。

コマンドライン引数

> py --help

とすると、最初に py.exe のヘルプ、その後に python のヘルプが表示されます。コマンドラインで指定できるオプションは次のとおりです。

コマンドライン引数 意味
-2 最新の Python 2.x が起動
-3 最新の Python 3.x が起動
-X.Y 「メジャーバージョンX.マイナーバージョンY」の Python が起動
-X.Y-32 「メジャーバージョンX.マイナーバージョンY」で 32 bit バージョンの Python が起動

最後の、32 bit を指定するには、マイナーバージョンまでの指定が必要です。最初にハイフンと数字で始まる引数は py.exe に渡され、それ以降の引数は、起動される python.exe に渡されます。

shebang行

Unix では、スクリプトファイルの先頭に #! で始まる行を置いて、起動するコマンドを指定することができますが、これを shebang と呼びます(「シバン」「シェバン」どちらの読みもあるようです)。py.exe はこの行を解釈することができます。たとえば、下のような行があると、/usr/bin を飛ばして、最後の python と、そのオプションだけを見てくれるのです。

これを py.exe から実行すると、次のようになります。

> py test.py
Python 2.7.5

これを実行すると下のようになります。

> py test.py
Python 3.3.2

Unix なら当たり前とはいえ、Windows でこれができるというのは、なかなか賢いでしょう? ファイルの関連付けをしておくと、test.py をダブルクリック、またはコマンドラインから直接実行したときに同じ振る舞いをします。Unix のようなことができるのですね。py.exe が解釈できる shebang 行の例をあげておきます。

shebang 実行されるPython
#!/usr/bin/python C:\Python27\python.exe(デフォルトの python)
#!/usr/local/bin/python2 C:\Python27\python.exe
#!/usr/bin/python3 C:\Python33\python.exe
#!/usr/bin/env python C:\Python27\python.exe(デフォルトの python)
#!python C:\Python27\python.exe(デフォルトの python)
#!C:\Python33\python C:\Python33\python.exe

初期設定ファイル(py.ini)

py.exe の振る舞いを設定ファイルで制御することができます。設定ファイルの名前は、py.ini で、置ける場所は、py.exe が存在する場所と、ユーザのアプリケーション・データ・ディレクトリ(*1)です。両方に存在する場合は、ユーザのディレクトリの方が優先されます。

  1. Windows Vista、Windows 7 では、%USERPROFILE%\AppData\Local。Windows XP では、%USERPROFILE%\Local Settings\Application Data となります。
    Python 2 で以下のスクリプトを実行すると、自分のディレクトリを知ることができます。

初期設定ファイルには、次のように、[defaults]と[commands]を記述することができます。[defaults]は、デフォルトで起動する Pytyhon のバージョンを指定することができます(大文字小文字が区別されます)。[commands]は、上の shebang 行に、キーを書いておくと、値のとおりに展開されるようになります。

上の設定なら、デフォルトで、Python 3.3 の 32 bit バージョンが起動され、shebang 行に、#!mypython と書くと、#!C:\Python33\python.exe -foo -bar と書いてあるものと見なされます。

環境変数

Windows の環境変数で、デフォルトの設定をすることもできます。この設定は、初期設定ファイルの設定を上書きします。

ドキュメント

上のリンク以外に、作者の Mark Hammond 氏と Martin v. Lowis 氏によるPEP 397があって、おそらく最も詳しい仕様の説明となっていますので、一読をお勧めします。この文書で使い方はすべて理解できると思いますが、日本語訳が見つからなかったので、翻訳を作りました。->http://dogwood.skr.jp/tmp/pep-0379-ja.txt

pydoc をコマンドラインで読む

IDLE を使っていると、F1 でオンラインドキュメントを参照できますが、通常のインストールなら、ローカルにもドキュメントがあります。この py.exe を使って、ドキュメントをコマンドラインで参照するための、バッチファイルを作ってみましょう。ファイル名は、pydoc.bat と pydoc3.bat としてありますが、何でもかまいません。C:\Python27 と C:\Python33 にパスが通っていますから、そこに置いてもいいし、他の場所でもかまいません。必要なら、@SETLOCALの後に環境変数を定義することもできます。

コマンドプロンプで下のように使います。

> pydoc sys      --> ビルトインモジュール sys のドキュメントを読む(ページャにmoreが使われます)
> pydoc -k print --> print ステートメント(関数)を含むドキュメントを列挙する
> pydoc -p 8080  --> ポート番号8080でサーバを開く http://localhost:8080 でアクセスできます
> pydoc -w print --> printステートメント(関数)のドキュメントを、print.htmlとしてカレントディレクトリに書きだす
--- 下の2つは、Python2.7 と Python3.3 で異なるオプションです ---
> pydoc -g       --> TCL/TKの検索窓を開く
> pydoc3 -b      --> ブラウザでドキュメントの検索ページを開く

デスクトップに置いてダブルクリックすると、シェルが即座に終了してしまうので、cmd.exe /K を%PY%の前に追加すれば、ウインドウをキープできますが、オプションが自在に指定できないので、お勧めしません。ドキュメントに従う限りでは、Python27(33)/Lib/pydoc.py をダブルクリックすれば、上のバッチファイルと同じコマンドラインになるはずですが、やはりシェルが終了と同時にウインドウが閉じてしまうような気がします。ショートカットを作って、オプション -g や -b を固定にするというような使い方もできると思いますが、そうすると、ウインドウが逆に閉じないのではないでしょうか(試してません)。いろいろ試して、お好きな設定を発見してください。

mintty を使う場合

MinGW の mintty は、対話モードのアプリケーションがうまく扱えません。対話モードで使いたい場合は、MinGW の mintty で対話モード、ついでに vim 設定をご覧ください。

mintty の設定ページで説明したとおり、winpty の console.exe を使って bash.exe を起動する場合、基本的に何の設定も必要ないと思いますが、タイプ量が多くなるものについての .bashrc 例です。pydoc.py は、それぞれ shebang があるので、そのままファイルを指定すれば起動できます。。3.3 の方は、デフォルトでないので、実行ファイルを指定します。py.exe や pyw.exe は普通に動作しますのでそのままでいいでしょう。IDLE はスタートメニューから起動するのが面倒な人向けです。

console.exe を個別のアプリケーション毎に使う使う場合の、エイリアス例です。

console.exe は、パスの通ったディレクトリにインストールすると思いますので、実際は、フルパスは必要ありません。pydoc 関連は対話モードではないので、上の例と同じです。前のセクションでも述べましたが、これで、コマンドラインで、

$ pydoc sys | less

などとすると、ドキュメントを読むことができます(この場合はページャを指定する必要があります)。pydocw と pydocw3 では、規定のブラウザで文書を読むことになりますが、2.x と 3.x では、pydoc のオプションが違っています。Python 2.x の TCL/TK を使った検索窓は、3.3 ではなくなってしまったようです。コマンドラインで、"pydoc -k <keyword>"して検索すればいいのですが、ブラウザで該当箇所に飛ぶ手段がありません。ブラウザを起動してから、検索ボックスで検索するという順番になってしまったようです。コマンドラインの方が楽かもしれませんね。また、残念ならが、オンラインのドキュメントを指定するオプションが存在しないようです。IDLE のヘルプは、オンラインドキュメントを参照するので、これを起動するモジュールがどこかにあるはずだと思いますが…現状は、ssh でリモートのサーバに接続し、vim を起動してコーディングしながら、マニュアルを参照し、また vim に戻るみたいな使い方ができるという程度ですね。初心者の私としては、まだ Eclipse の PyDev を使うほど大きなプログラムは書けないので、vim の補完とこのマニュアルで十分なのです。

なお、IDLE の設定ファイルは、ユーザのホームディレクトリの .idlerc に入ります。Windows と MinGW 環境で別になっている場合は、それぞれのホームディレクトリに作成されます。

winpty を使いたくない場合は、明示的にオプションをつける必要があります。バージョンを指定する引数は、第一引数でなければならないので、エイリアスで、’py -i’としてしまうと、バージョンの指定の引数が python.exe に渡ってしまいます。このため、対話モードで起動したいときには、-i オプションをつけなければなりません。

$ py -i
$ py -3 -i
$ python -i
$ /C/Python33/python -i

XAMPP 1.8.3 で Python

XAMPP for Windows 1.8.2 がリリースされているので、入れ替えようと思ったら、1.8.3 がダウンロードできるようになっています。ページトップには、「XAMPP新バージョン 1.8.2 をリリースしました!」となっているのですが、1.8.3 はリリース版ではないということでしょうか? このバージョンから、Windows 2000、XP、2003 をサポートがなくなっているようです。 よくわかりませんが、ポータブル版を入れました。それぞれのバージョンは下のようになっています。1.8.2 との違いは、MySQL と PHP のバージョンだけです。ついに mysql ドライバ非推奨の環境に突入ですね。

ソフトウェア バージョン
Apaceh 2.4.4
MySQL 5.6.11
PHP 5.5.3
Tomcat 7.0.42
Strawberry Perl 5.16.3.1

いつの間にか、ポータブル版でも Tomcat と Perl が含まれるようになっていました(いらないのですが…)。PHP が 5.5 になりましたので、WordPress を DEBUG モードで動かすと、log がとんでもないことになりそうです。bitnamiがライブラリを提供することになったらしく、WordPress、Joomla!、Drupal のインストールリンクが追加されていました。

CGI として使う

インストールした先の Apache 設定ファイル(\xampp\apache\conf\httpd.conf)に、拡張子 .py を cgi script として登録します。

お好みで、DrectoryIndex に index.py を追加してください。\xampp\htdocs 以下に test.py を作って実験してみます。Python を Web 上で使うには HOWTOを参照。

ブラウザで、http://localhost/test.py にアクセスすると、’Hello, Python 2.7 was here!’ が見えるはずです。cgi として動かすスクリプトファイルで使える shebang 行は次のとおり。py.exe は -3 を指定しても同じ動作になります。Apache が読むので、py.exe 単体で使える「仮想コマンド」は、残念ながら利用できません。オプションなしの py.exe は、環境変数を設定すれば動作するかもしれませんが、どちらにしろ、コマンドプロンプトが開いてしまうので、使えないでしょう。これは、py.exe の仕様上、他のプロセスから実行されることは考慮していないので、仕方ありません。

shebang 結果
#! python OK 環境変数%PATH%で最初に見つかったpython.exeが起動
#! C:\Pytho27\python OK
#! py -2 OKだが、コマンドプロンプトのウィンドウが開く
#! C:\Python33\py -2 上と同じ
#! py コマンドプロンプトのウィンドウが開き、入力待ち、というか、プロセスが死ぬ
#! C:\Python33\py 上と同じ
#! /usr/bin/python Internal Server Error

mod_wsgiを使う場合

【2014-02-21 追記】

以前は、

modwsgiで配布しているバイナリは、そのままでは XAMPP 1.8.3 の Apache が読み込めません(起動に失敗します)。

と書きましたが、code.google.com では、Windows 用バイナリの配布をやめたようです。かわりに、Unofficial Windows Binaries for Python Extension Packagesが、VC 10 と VC 11 でコンパイルしたバイナリを配布しています。XAMPP 1.8.3 の Apache は、VC 11 でコンパイルされていますから、VC 11 用のバイナリを使うと、ちゃんと動かせるようになりました。

インストール、および設定は、code.google.com のページで読むことができますが、簡単なところだけ採録しておきます。

  1. アーカイブに含まれる mod_wsgi.so を、apache/modules ディレクトリにコピーする。
  2. apache/conf/httpd.conf に LoadModule ディレクティブを追加する。
  3. apache/conf/extra/httpd-vhosts.conf でバーチャルホストの設定をする。
  4. C:\Windows\system32\drivers\etc\hosts ファイルにバーチャルホストのアドレスを追加する。

"NameVirtualHost *:80"は必要なくなりました。

これで、http://localhost.python.com/myapp にブラウザでアクセスし、"Python was here!"と表示されれば成功です。

副作用

Notepad++

Python 2.7.5 をインストールすると、notepad++ のプラグイン Python Script が動作不良になります。また、この Python Script に依存する Emmet も動作しなくなってしまいます。プラグインに付属の python27.dll のバージョンが、インストールされたものと一致しないようで、モジュールの読み込みに失敗しているようです。

notepad++ のインストールディレクトリにある python27.dll を削除すれば、インストールした Python を自動的に使うようになります。なお、64 bit 版の Python 2.x では動作しませんでした。

Vim

vim orgで配布されている Vim7.4 は、Python のサポートが外されていて、IME も使えないので、transparency パッチだけを使い、Python と IME を有効にして、Visual Studio で 32bit 版と 64bit 版をコンパイルし直しましたが、32bit 版 vim では、64bit 版の pythonX.Y.dll を読み込めず、64bit 版 vim では、32bit 版の pythonX.Y.dll を読み込めません。vim の実行ファイルに合わせた Python をインストールしろということですね。

SQLite Integration 1.4.2 アップデート

English version is available in SQLite Integration 1.4.2 updated

SQLite Integrationを 1.4.2 にアップデートしました。

  1. WordPress 3.7.1 でのインストールをテストしました。
  2. サーバ情報を表示する関数のバグ、その他を修正しました。
  3. スクリーンショットを差し替えました。

その他のバグを見つけたら、このサイトでコメントを残すか、サポート・フォーラムにポストしてください。

SQLite Integration 1.4.2 updated

Japanese version is available in SQLite Integration 1.4.2 アップデート

SQLite Integration was updated to the version 1.4.2.

  1. Tested WordPress 3.7.1 installation.
  2. Fixed the bugs of the function for displaying the server information and some minor bugs.
  3. Changed the screenshot.

When you notice malfunctioning or bug, I’ll be glad to hear from you via the comment on this site or the post to the support forum. Thank you.

MinGW の mintty で対話モード、ついでに vim 設定

English version is not available.

MinGW 版 mintty の現在

MinGW に含まれる mintty は対話モードを必要とする Windows ネイティブ・アプリケーションをうまく扱えません。sqlite3 や Python、Node.js や Git などが、この影響を受けます。対話モードで起動するオプションを持っているものは、"-interactive" や "-i" オプションをつけて起動すれば利用できますが、オプションがないものは手がありません。

これは、mintty を使う人なら周知の事実です。見なかった振りをすることもできますが、sqlite3、Python、Node.js、Git が仕様どおり使えないのは困るので、対策をしました。

通常のインストールなら、コマンドラインで、man mintty すると、マニュアルページを読むことができます。それを見ていくと、「制限事項」の最初にこの問題についての説明があります(拙訳ですが、日本語にしました)。

制限事項
コンソール問題
Minttyは、Cygwinがデフォルトで使いますが、Windowsのコンソールウインドウを完全に置き換える、というものではありません。xtermやrxvtと同じように、minttyも、子プロセスとは疑似ターミナルデバイスを通して通信します。CygwinはWindowsのパイプを利用してこの疑似ターミナルデバイスをエミュレートします。これによって、minttyから起動したWindowsネイティブのコマンドラインプログラムは、コンソールデバイスではなくて、パイプを見ることになります。その結果、そうしたプログラムにおいて、対話的な入力ができなくなることがしばしばあります。また、低レベルのWin32コンソール関数を直接呼ぶことができません。それでも、ファイルとしてコンソールに接続するプログラムはうまく動作するはずです。

MinGW では、コンソールへの入出力に /dev/tty[0] だけでなく、/dev/conout と /dev/conin という疑似デバイスを使うことができます。Windows で、コンソールをファイルとして開いた場合に、ファイル名として使う"CONOUT$"、"CONIN$"に対応しているようです(msdn: CreateFileを参照)。これらは実際にデバイスがあるというわけではないのですが、下のように、"ls デバイス名"とすると、あたかもファイルが存在するかのように見ることができます。ワイルドカードは使えません。tty コマンドでは、/dev/tty0 が返ります。

$ ls -al /dev/tty
crw-rw-rw- 1 user Administrators 5, 0 Nov  6 17:14 /dev/tty
$ tty
/dev/tty0

端末関係をまとめると、下のようになります。/dev/console は存在しないようです。

疑似デバイス名 接続先 疑似デバイス名 接続先
/dev/tty 入出力コンソール /dev/tty[0-?] 入出力コンソール(有効なのはtty0だけ)
/dev/ptmx 開けない /dev/ttyS[0-?] シリアルポート(利用不可)
/dev/conin 入力コンソール /dev/conout 出力コンソール

これらは、当然ながら、素の bash.exe でなら、下のように読み書きができます。もちろん、python.exe や node.exe を対話モードで使うことができます。

> bash
bash-3.1 $ echo hello > /dev/conout
hello
bash-3.1 $ cat /dev/conin
hello  (← キーボードから入力)
hello
bash-3.1 $ echo hello > /dev/tty
hello
bash-3.1 $ cat /dev/tty
hello  (← キーボードから入力)
hello
^C
bash-3.1 $

ところが、mintty を使って、bash.exe を起動すると、下のようになります。

> mintty -V
mintty 1.1.3
(C) 2013 Andy Koppe
License GPLv3+: GNU GPL version 3 or later
There is no warranty, to the extent permitted by law.

> mintty -e bash --login
$ echo hello > /dev/conout
$ (←プロンプトだけが返る)
$ echo hello > /dev/tty
hello
$ cat /dev/conin
cat: /dev/conin: Bad file number
$ cat /dev/tty
hello (←キーボードから入力)
hello
^C
$

/dev/conin、/dev/conout を使ったコンソールとの通信ができなくなるのですね。もし、Windows のファイルディスクリプタ CONOUT$ と CONIN$ がここにつながるとすると、mintty には制御できないということになりそうです。また、パイプラインについては、下で実験していますので、参照してください。アプリケーション側が、入出力がパイプだと判断すると、対話モードで起動しなくなる原因になります。

winpty というラッパ

さて、この現象の詳細ですが、Issue 56: Improve support for native console programs での議論がとても参考になります。作者 Andy Koppe さんの、

"python -i" があるんだから、それを使えばいいじゃん。

という意見はまったくそのとおりです。できないことはやらない、というソフトウェアの基本ですね。ところが、Andy Koppe さん、数か月後には、conin.exe というラッパを作って公開しています(#21の投稿)。この conin.exe は、いくつかのサイトで紹介されています。これでラップすると、Win32 アプリケーションでも対話モードで使えるようになるそうです。しかし、これは大量の Cygwin の dlls を必要とするので、MinGW 環境では使えません。それに、たぶんもうメンテナンスされていません。

ところが、その後、この議論の中で、Ryan Pricahrd という方が、2012年4月に、こんなのをつくったけど、といって、winpty というラッパをアナウンスしました。ありがたいことに、Cygwin 版と、MinGW 版があります(ソースは一つです)。上の code.google.com での議論を読むと、Console2 と同じ手法、ということは、ConEmu と同じ手法、ということは、conin.exe と同手法を使っている、ということになるようです。もうこの方法しかない、というように議論が収斂していく中で作られた様子がよくわかります。

この winpty を使うと、ほぼ望むとおりの振る舞いをしてくれます。Console2 のように表示が乱れるということもありません。

リンク先の GitHub からバイナリをダウンロードして、実行ファイルとライブラリをパスの通ったところに置けばインストールは終了です。通常どおり mintty を起動して、Windows アプリケーションは console.exe でラップするという使い方をするか、起動時に bash.exe そのものをラップしてしまうか、どちらかの使い方をします。

通常起動の場合、

$ /use/local/bin/console.exe python.exe

というようにしますが、フルパスで指定する必要はありません。タイピングの量が増えるので、.bashrc でエイリアス指定した方がいいでしょう。こんな感じです。

bash.exe をラップしてしまう場合は、エイリアスは必要なくて、mintty の起動スクリプトで、

というように指定します。

mintty + bash と、console.exe をかませたものとを比較した結果が、Issue 56: Improve support for native console programsの#67で投稿されています。console.exe を使った方が若干遅くなっているようです。同じテストをしてみると、私の環境では、下のようになりました。10万回 test を出力するテストです。

mintty.exe /bin/bash –login で起動した場合。

real   1m56.810s
user   0m2.917s
sys    0m0.733s

mintty.exe /usr/local/bin/console.exe /bin/bash –login で起動した場合。

real   0m13.515s
user   0m2.060s
sys    0m1.045s

投稿の結果とは逆です。下の場合が速いというよりも、mintty + bash の表示にかかる時間が長すぎます(原因は調べてませんが)。user の CPU 時間は 2.0s を切ることはないようです。だいたいこんなもの、と思ってください。ちなみに、cmd.exe から bash だけを起動して試すと、下のような結果でした。

real   0m17.612s
user   0m1.872s
sys    0m0.874s

表示ではなくて、計算するだけのテストもやってみました。Learning Python 第4版の p.509-511 にある例を使います。abs()ではなくて、加算の方を使いました。本をお持ちでない方のために説明しておくと、x + 10 という加算を、python の for ループ、リスト内包表記、map 関数、ジェネレータ式、ジェネレータ関数を使って、それぞれの時間を計測するというものです。画面表示があまり影響せず、計算の速度を比較するものと思ってください。

Windows の cmd.exe を使った場合。

> py -3 timeseqs.py
3.3.2 (v3.3.2:d047928ae3f6, May 16 2013, 00:06:53) [MSC v.1600 64 bit (AMD64)]
---------------------------------
forLoop  : 2.72152 => [10...10009]
---------------------------------
listComp : 1.63735 => [10...10009]
---------------------------------
mapCall  : 3.04892 => [10...10009]
---------------------------------
genExpr  : 2.10303 => [10...10009]
---------------------------------
genFunc  : 2.11403 => [10...10009]

mintty.exe /bin/bash –login の場合。

$ py -3 timeseqs.py
3.3.2 (v3.3.2:d047928ae3f6, May 16 2013, 00:06:53) [MSC v.1600 64 bit (AMD64)]
---------------------------------
forLoop  : 2.75238 => [10...10009]
---------------------------------
listComp : 1.75466 => [10...10009]
---------------------------------
mapCall  : 3.22996 => [10...10009]
---------------------------------
genExpr  : 2.29178 => [10...10009]
---------------------------------
genFunc  : 2.23834 => [10...10009]

mintty.exe /usr/local/bin/console.exe /bin/bash –login の場合。

$ py -3 timeseqs.py
3.3.2 (v3.3.2:d047928ae3f6, May 16 2013, 00:06:53) [MSC v.1600 64 bit (AMD64)]
---------------------------------
forLoop  : 2.83609 => [10...10009]
---------------------------------
listComp : 1.76609 => [10...10009]
---------------------------------
mapCall  : 3.37456 => [10...10009]
---------------------------------
genExpr  : 2.21019 => [10...10009]
---------------------------------
genFunc  : 2.23722 => [10...10009]

ちょっと微妙な感じですね。もう少し負荷をかけた処理をさせると、違いがはっきりするのかもしれませんが、大きな差は出ないようです。

不具合

  1. bash をラップして使うと、ssh でリモートのサーバに接続したときに、文字化けします。mintty の言語設定、サーバ側の言語設定がどちらも UTF-8 となっていても文字化けします。
  2. less を使うときに、方向キーがきかず、[jk]とスペースキーでしか行送りができなくなります。
  3. 子プロセスが異常終了したときに、ゾンビになることがあります。
  4. 子プロセスが異常終了したときに、まきこまれて winpty が死ぬときがあります。
  5. JavaScript、例えば、Node.js の uglifyjs などを、"console.exe uglifyjs" としては使えません。bash をラップしたコマンドラインでは使えます。
  6. 試していませんが、irb が対話モードにならないという情報もあります。
  7. vim を使うときに、日本語入力や外部コマンドの出力との関連で、何かを犠牲にしなければならないという状況になります。色づけとの関連では、termcap をうまく扱えていないのかもしれません。(おまけ参照)

mintty から起動した Windows アプリケーションのコンソール出力

code.google の議論では、Windows アプリケーションが WriteConsole 関数を使うのが原因では、という人もいたので、msdnの、WriteConsoleを参考に、試してみました。コンソールを開いて、"Hello, World"を書きだす C コードです。

Visual Studio 2012 Express に付属の cl.exe と、MinGW の gcc でコンパイルしてみました(どちらも結果は同じです)。

mintty bash –login で起動後、実行します。

$ ./conTest.exe
$

プロンプトが返るだけです。試しに、GetStdHandle() の引数を STD_ERROR_HANDLE に変えても同じでした。次に、mintty console bash –login で起動して、実行すると。

$ ./conTest.exe
Hello, World!
$

たしかに、console.exe があると、出力を捕捉してくれるようになります。このとき、conTest.exe が開いているコンソールは、mintty が裏で開いているデバイスにつながっていないのですね。

マニュアルページにあったように、コンソールをファイルとして開いた場合はどうなるか、確認してみましょう。

実行してみましょう。mintty bash –login の場合。

$ ./conFile.exe
$

同じです。mintty console bash –login の場合。

$ ./conFile.exe
Hello, World!
$

WriteConsole()、WriteFile() ともに失敗します。CreateFile() 関数に指定できるコンソールハンドルは、CONOUT$ と CONIN$ だけで、エラー出力へのハンドルは取得できないようです。マニュアルページで触れられていた「ファイル」というのは、これとは違う意味なのでしょうか?

それでは、通常の stdout、stdin はどうでしょうか。prinf() ではなくて、明示的に stdout、stdin を指定してみます。

これを実行すると、どちらも

$ ./output.exe
a
$

と出力されます。入力も試してみましょう(懐かしい K & R のコードです)。

これはちょっと変わります。mintty bash –login で実行させると次のようになります。

$ ./io.exe
a (←キーボードから入力)
b (←キーボードから入力)
x (←キーボードから入力)
a
b
$

おっと、入力がバッファにたまって出てきません。このバッファリングは、putc() の後に、fflush(stdout) すると、ちゃんと出力されますので、コンソール問題とは別です。mintty console bash –login で実行すると、こうなります。

$ ./io.exe
a (←キーボードから入力)
a
b (←キーボードから入力)
b
x (←キーボードから入力)
$

期待どおりの出力です。ここまでで、mintty が出力をコントロールできないのは、Windows アプリケーションがコンソールデバイスに出力を書き込んだときだというところまではわかりました。ちょっと覗いたところでは、mintty が子プロセスを fork() したときに、Windows のコンソールを開いているようですが、細かいところまではわかりません。それに、fork() の機構がないはずの MinGW でどうやってコンパイルするのかもわかりません。

それでは、「入出力がパイプラインになっている」というのを調べてみます。

cl でも gcc でもコンパイルできるはずですので、試してみてください。

mintty + bash です。

$ ./crt_isatty.exe
stdout has been redirected to a file
stdin has been redirected to a file
stdout is a pipe
stdin is a pipe

winpty + mintty + bash です。

$ ./crt_isatty.exe
stdout has not been redirected to a file
stdin has not been redirected to a file
stdout is a terminal
stdin is a terminal

Windows の cmd.exe です。

> crt_isatty.exe
stdout has not been redirected to a file
stdin has not been redirected to a file
stdout is a terminal
stdin is a terminal

素の mintty は、入出力がリダイレクトされて、パイプになっている、と返すのですね。これをチェックするプログラムなら、対話モードにならないでしょう。これを winpty は違う応答を返すようにしているのですね。isatty() または _isatty() でチェックする Python のようなアプリケーションは、これで対話モードで起動するようになるわけです。

おまけ: MinGW 付属の vim 設定

MinGW に付属の /usr/bin/vim.exe は、単独で配布されている Windows 版 vim とも、その日本語版とも違っているので、両者を併用するときには、.vimrc の中で場合分けが必要です。また、winpty を使う場合にも、少し挙動が変わるようです。

Windows 版の vim は、Windows アプリケーションなので、それ用にちゃんとチューニングされているようですが、コンソール用の vim.exe でも、さすがに mintty で使うことは想定していません。また、MinGW のそれは、あくまで MinGW アプリケーションなので、termcap を使っているなど、Unix 寄りになっていますが、POSIX 準拠の Cygwin ほどは Unix になっていないようです。

下の設定は、GUI ではなくて、mintty の中で起動して、日本語の表示と編集ができて、キーワードの色付けができるるところまでの設定です。winpty を使った場合に、TERM=xterm-color を指定してあるのは、.vimrc の中で場合分けができるようにするだけでなくて、これがないと日本語が表示できず、IME からの入力もうまくいかないので、必須の設定です。msys-vim の設定だけで、Windows 用 gvim の設定は入っていません。

.inputrc

/etc/inputrc.default を ~/.inputrc にコピーして、次のようにしてあります。

.bashrc

ロケール、文字コード設定。

console.exe で bash.exe をラップしている場合。

コマンド毎に console.exe を設定している場合。どちらも console.exe は使いません(*1)

  1. [2013-11-28 追記] Windows 版 の vim.exe には、console.exe を使わないと、画面描画ができませんでした。また、vim –help の日本語がうまく表示できません。ここの部分は下のように訂正します。 または、下のように、シェルスクリプトにするという手があります。WITHOUT_CONSOLE は、winpty を使わない mintty の起動スクリプトで環境変数を設定してあります。

.vimrc

実際は、Windows 版 vim との併用になるので、バージョン番号で場合分けをしたりしていますが、MinGW 付属の vim に関係するところだけをあげます。その他の設定は通常の vim と共通です。

色の設定は、Using vim color schemes with Puttyを参考にしましたが、256 色や 16 色では、表示が乱れるので、8としてあります(と、書きましたが、16 色でいけました: 2012-11-30追記)。winpty ありの方のキーマップ指定は、これがないと、カーソルキーが動かなくなり、vi 互換のような振る舞いをしてしまいます。

設定一覧

vim 項目 winptyあり winptyなし
msys-vim .minttyrc Locale=ja_JP
Charset=UTF-8
Locale=ja_JP
Charset=UTF-8
.bashrc LANG=ja_JP.UTF-8
OUTPUT_CHARSET=UTF-8
LANG=ja_JP.UTF-8
OUTPUT_CHARSET=UTF-8
.vimrc encoding=cp932
termencoding=cp932
encoding=cp932
termencoding=utf-8
日本語IME 使える 使える
:!ls の日本語 –show-control-charsが必要 できない(*1)
:!dir の日本語 できない できない
gvim .minttyrc Locale=ja_JP
Charset=UTF-8
Locale=ja_JP
Charset=UTF-8
.bashrc LANG=ja_JP.UTF-8
OUTPUT_CHARSET=UTF-8
LANG=ja_JP.UTF-8
OUTPUT_CHARSET=UTF-8
.vimrc encoding=cp932
termencoding=cp932
encoding=cp932
termencoding=cp932
日本語IME 使える 使える
:!ls の日本語 –show-control-charsが必要 –show-control-charsが必要
:!dir の日本語 できる できる
  1. mintty の charset と vim の termencoding を SJIS にして、–show-control-chars すれば日本語が読めますが、表示が乱れます。何より、日本語入力ができなくなってしますのでお勧めしません。

ls の出力は、msys-vim も gvim も、MinGW の /bin/ls.exe を使っていて、/bin/sh.exe や vimrun.exe から実行するようなので、.bashrc で ls に –show-control-chars をつけてエイリアスしていても、ここでは使われません。また、gvim の dir は、cmd.exe 組み込みのものが使われるようです。

制限事項

無理なことをしているわけですから、完全に満足のいく結果を求めてはいけないのですが、制限事項というか、どうしても直せないところが残りました。

  1. CursorLine に色づけをしたとき、winpty なしの msys-vim 以外はカーソルの次の行までハイライトされてしまいます。CursorColumn は正常です。
  2. winpty ありで gui でない Windows 版 vim をオプションなしで起動すると、スプラッシュスクリーン(というのでしょうか?)が表示されません。kaoriya 版も同様です。

Eclipseワードラップ用プラグイン

English version is not available.

小さな修正なら、今でもエディタでコーディングをすることも多いけれども、大きなプログラムを扱うときには、主にEclipse を使っています。けれども、長い行を折り返す機能のがないというのが不便に感じるところでした。改行が重要な意味を持つVisual BasicやPythonのような言語でプログラミングするなら、余計な折り返しはしてほしくないという気持ちはわかります。私自身は、HTMLマークアップを使うようになってから、パラグラフを1行で書く習慣がいつの間にかできたような気がします。\(\TeX\)のつもりでパラグラフを書いていたら、ブラウザでは妙なところで改行されていたりして、いわば「教育(去勢)された」ということかもしれません。フォーラムを見ると、少ないながら、行折り返し機能の要望はあるようなのですが、気にしない人も多いようです。由緒正しいエディタであるEmacsやVimはもちろん、Eclipseもまた初期設定では折り返しをしてくれないのです。これがエディタの通常動作ということなのでしょう。

EmacsやVimでは、設定ファイルで、Eclipseはプラグインでワードラップを実現します。

ところが、このプラグイン(Eclipse Word-Wrap)、行番号の表示が狂ったりして、いまいち扱いにくいなぁ、と思っていたら、ちゃんとありました。別のプラグインを開発している人がいらっしゃいました。Florian Weßlingという方です。ドメインからするとドイツの方ですが、「フロリアン・ヴェスリンク」と読むのでしょうか。Eclipse のCommunity Forumを見ていたら、彼の書込みがあって、知りました。現在は、Keplerでも使えるものが配布されています。彼のページはhttp://dev.cdhq.de/eclipse/です。

プラグインの配布は、Eclipse Word-Wrap Plug-Inで行われています。説明ページのスクリーンショットを見れば一目瞭然ですから、ここでは画像を載せませんが、そうなってほしいなぁという通りに表示されます。

Florian Weßlingさんは\(\LaTeX\)使いなので、スクリーンショットは TeXlipseのソースコードになっています。\(\TeX\)では、パラグラフの中の改行は自由にできるので、書くときには特にワードラップしなければ困るということはないと思うのですが、不思議なものですね。そんな人からワードラップ用プラグインが出てくるのですから。たぶん、\(\TeX\)のエラーコンソールから一発でソースの該当箇所に飛ぶときに(TeXlipseならそれくらいできるでしょう、たぶん)、イライラしたことがあったのではないかと想像しますが、わかりません。

導入方法は配布ページで説明されている通りなので、ここでは書きませんが、使ってみると、ちゃんと行番号と改行があっているし、キー操作でトグルできるので、たいへん快適な使い心地です。

*
*  *
2013-10-19 追記

使い心地はいいのですが、問題点が一つありました。Emmet を使っていると、Expand Abbreviation が動きません。これは参ります。Word-Wrap プラグインのファイルを削除すると、Emmet はちゃんと動作するので、明らかに Word-Wrap プラグインが原因です。

作者の Florian Weßling さんにメールで報告しました。

*
*  *
2013-10-23 追記

Weßling さんから報告をもらいました。「問題については認識しているけれども、まだ解決策を見つけられていません。次のリリースで何ができるか見るようにします」とのことです。Java Master のみなさん、Eclipse Master のみなさん、修正案を思いついたら協力しましょう。

SQLite Integration 1.4.1 アップデート

English version is available in SQLite Integration 1.4.1 updated

SQLite Integrationを 1.4.1 にアップデートしました。

  1. バージョン 1.3 で入れた、BETWEEN 関数のサポートで、記事の本文が書き変わってしまうバグを修正しました。
  2. ダッシュボードのでMP6を使っている場合にメニューがずれてしまうのを修正しました。
  3. SELECT version()クエリがダミーのデータを返すようにしました。

NewStatPress で使われている BETWEEN 関数を SQLite が解釈できるように書き換えるコードを追加しましたが、構文が自然言語とまったく同じ、between A and B なので、投稿の内容を書き換えてしまうバグとなってしまいました。投稿本文が消えるという症状なので、クリティカルと判断し、アップデートしました。なお、このバグはフォーラムでの報告で判明しました。zoomosis氏のリポートに感謝します。

対策は、クエリを分割して、クオートを数え、投稿本文かクエリの一部かを判定するようにしましたが、その分のオーバーヘッドがあります。安全を優先しました。

その他、前回修正し切れなかった部分を修正してあります。

コミットした後、またしても日本語カタログのミスを発見しました。あぁ…

SQLite Integration 1.4.1 updated

Japanese version is available in SQLite Integration 1.4.1 アップデート

SQLite Integration was updated to the version 1.4.1.

  1. Rewrote the manipulation of BETWEEN funciton support introduced since version 1.3.
  2. Fixed the style corruption when using MP6 plugin.
  3. SELECT version() query returns a dummy data.

I added the support for BETWEEN function for NewStatPress plugin. The function rewrites the post content when it contains ‘between A and B’ phrase, and the post data disappears, which I think is critical and needs upgrading. This bug was informed in the support forum. I appreciate zoomosis’ report.

New procedure will split the SQL statement into tokens, count the single quote and check if the BETWEEN is in the post content or a part of SQL statement. This will make the system a little slower, but I prefer the safety to the speed.

Other minor bug fixes are included.

SQLite Integration 1.4 released

Japanese version is available in SQLite Integration 1.4 リリース

SQLite Integration was updated to the version 1.4.

  1. Added the database utility to fix the database caused by upgrading WordPress 3.5.x to 3.6.
  2. Fixed the bugs of ALTER TABLE query.
  3. Changed the manipulation of SHOW INDEX with WHERE clause.

When you insatalled WordPress 3.5.x with this plugin and updated to WordPress 3.6, upgrading was not well finished and there’re some columns that lost default values property. Ordinary usage of the database shows no mulfunction or error messages, but some plugins depending the default value of the column will cause the problem. The bug report of the support forum gave me a clue about this problem.

You’ve got to access your database to fix this problem, but it’s a little difficult to do the job. SQLiteManager distributed as a utility for manipulating SQLite databases can’t change the property of the column. It doesn’t behave as you expected and seems to be a bug, I guess. SQLite Manager, a Firefox Addon, doesn’t seem to do this job. So I added the new page on the admin dashboard and let the users do the fixing database job by clicking the buttons. If above is your case, please be sure to visit the dashboard and do this job.

If you are using WordPress 3.5.x or install a new WordPress 3.6, you don’t have to do this job.

I changed some codes for other plugins to work fine.

Just after I committed the version 1.4, WordPress is upgrade to 3.6.1 (!). I did try upgrading it without problem. This table shows the conbinations of S(QLite) I(ntegration) with W(ord)P(ress) and if the above fix is necessary or not. Version 1.3 means 1.3 or lesser.

SI WP Current => WP Updated Fixing job
1.3 3.5.x => 3.6 Need updating to 1.4 and fixing
1.3 3.5.x => 3.6.1 Need updating to 1.4 and fixing
1.3 3.6 => 3.6.1 Not necessary; upgrading to 1.4 is recommended
1.4 3.5.x => 3.6 Not necessary
1.4 3.5.x => 3.6.1 Not necessary
1.4 3.6 => 3.6.1 Not necessary

Further more, if you are using MP6 plugin, selected dashboard menu is displayed indented. I’ll fix it at next release. If you fix it right away, please download a development version from http://wordpress.org/plugins/sqlite-integration/developers/ and replace three files below.

  • styles/doc.css
  • styles/style.css
  • utilities/documentation.php

When you notice mulfunctioning or bug, I’ll be glad to receive your report by the comment in this site or posting to the support forum. Thank you.

1 / 41234