理由が馬鹿らしくて。

こんなスタックトレースなの：

 1 Traceback (most recent call last):
 2   File "./pygmentize_cgi.py", line 567, in <module>
 3     main()
 4   File "./pygmentize_cgi.py", line 555, in main
 5     _responder.content_charset[1]))
 6   File "./pygmentize_cgi.py", line 387, in _format
 7     lexer = get_lexer_by_name(lang, **extra_params)
 8   File "/path/to/pygments/lexers/__init__.py", line 88, in get_lexer_by_name
 9     return _lexer_cache[name](**options)
10   File "/path/to/pygments/lexer.py", line 583, in __call__
11     return type.__call__(cls, *args, **kwds)
12   File "/path/to/pygments/lexers/php.py", line 223, in __init__
13     from pygments.lexers._php_builtins import MODULES
14 EOFError: EOF read where object expected

pygments.lexers._php_builtins については、Pygments を Mercurial の head を持ってきたときに本当に壊れていたことがあったので、それだと思ったんだけど、これはそうじゃなくて。単に pyc のアップロードが「不完全」で壊れていただけだった。

何が起こったかって? pygmentize_cgiをサービスするのにね、「ロリポップ!のPythonは本当にただのPython」なので、どこかにPygmentsをアップロードしないといけないわけなのね。で、pyc が入ってない状態でアップロードすりゃいいものを、何を狂ったか、site-packages から引っこ抜いて転送し、そして失敗していた。

なんだろうなぁ、WinSCP が悪いのか、それとも単に FTP のプロトコルが抱えている問題なのかはわからないんだけど、頻繁に「なんの報告もなく」失敗するんだよね。ファイルサイズで辛うじて気付くことは多いんだけど、フォルダをまとめてアップロードしたような場合は、まず普通は気付かない。

失敗するのはだいたいは大きなファイルで、_php_builtins.py が大きいので、_php_builtins.pyc も当然大きい。だから失敗したんだろう。

本当は、時間もかかるんで、「フォルダをそのまま」アップロードすること自体が好みではなくて、アーカイブを転送して、転送先で展開したい、のだけど、ロリポップ！のロリポプランでは「リモートログイン」の手段がないので、これを簡単にやる方法はないんだよね。まぁアーカイブを転送するのでも「アップロード失敗」問題は付きまとうけれど、対象が一個なので、失敗してれば気付く可能性は高いので、その方がマシなはずよね。

pyc だけが失敗した、という保障はないんだけれど、そもそも pyc を「アップロード」した意味なんかないんだから、いったん全部消してしまおうと思った：

1 #! /bin/sh
2 cd /path/to/home/
3 find . -name '*.pyc' -exec rm -f '{}' \;

これをスクリプトにしておいて、cron に登録して…。あぁ、馬鹿馬鹿しい。いまだ「ロリポプラン」のままなんだけど、こういうのがあるたびに、「やっぱチカッパプランだよな」と思う。

そうそう。全然この話とは関係ないんだけど、WinSCP について。これまでずっと「ドットファイル」を表示する方法がわからず困っていた。これは「Ctrl-ALT-h」だって。もしくは：

なんかわかりにくいぞ。