WordPressに移行しました

http://kanonji.info/blog/

ちょっとずつ準備していたWordPressだけど、最低限の環境は整ったので移転することにしました。どちらかというと、はてなダイアリーに不満があるからっていうより、WordPressでやりたい事が増えてきたからというのが理由です。


はてなダイアリーは2008年11月からなので、書き続けて4年強。266エントリー程度書いたみたいです。1年平均で66.5エントリーなので、思ったほど書いてないですね。はてなダイアリーは、はてな記法やシンタックスハイライトなど、プログラマーフレンドリーでいいサービスなんですが、WordPressの自由度が欲しくなりました。

移転しても別に書く内容は変わらず、淡々と書き続けると思います。せっかくWordPressにするので、WordPressのエントリーは増やしていきたいです。

coreserverでphp5.3.8用のAPCをビルドしてみたけどうまくいかなかった

coreserverのPHPは5.2.5がデフォルトだけど、CGIモードにすると5.3.8か5.4.7が使えます。CakePHP2系は5.2.8以上が必要なので、coreserverでCakePHP2系を使うならCGIモードで5.3.8以上のどちらかにしないとです。
ただ、この5.3.8 / 5.4.7にするとcoreserverでのAPC(Alternative PHP Cache)について調べてみた - kanonjiの日記で調べたapc.soが動かない事に気がつきました。ちょっとレスポンスが悪く、APCを使いたいなと思っていたところなので、なんとかしようと、APCをソースからビルドしようと色々やってみました。結果は行き詰まってしまって、お手上げ状態なんだけど、やってみた事をまとめておきます。

CGIモードのphp 5.3.8にapc.soを読み込んだ時のエラー

Script Error

The script did not produce proper HTTP headers. Please see the error log to see the detail of the errors. Depending on the server configuration, you can also run thisscript under CGIWrap debugging. Usually, either rename or linkthe script temporarily to a file which ends with .phpdextension, or add a AddType application/x-httpd-phpcgi-debug .phpline to your .htaccess file.

見慣れないエラー、多分phpじゃなくApacheのエラーだと思う。
デバッグ方法が書いてあるけど、まずはcoreserver上に5.3.8 / 5.4.7用のapc.soが無いか探したり、その流れでビルドを試しました。

色々試す中、CGIモードphpのバージョンを5.3.8と5.4.7とで、何度も切り替えてたので、コマンドとかが5.3だったり5.4だったりします。が、解決しない事は一緒だし恐らく問題点も一緒だと思います。

APCをソースコードからビルドしたけど、やっぱり上記のエラー

$ curl -LO http://pecl.php.net/get/APC-3.1.14.tgz
$ tar xzvf APC-3.1.14.tgz
$ cd APC-3.1.14
$ php54ize --clean
$ php54ize
Configuring for:
PHP Api Version:         20041225
Zend Module Api No:      20060613
Zend Extension Api No:   220060519
$ ./configure --enable-apc \
 --with-php-config=/usr/local/bin/php54-config \
 --prefix=/virtual/myuser/myhome/local/lib/php54/extensions
$ make
$ make install

ここで、なぜか--prefix指定を無視して/usr/localにinstallする動きをします。共用サーバーなので当然パーミッションは無く書き込めないけど、なぜ--prefixが無視されるんだろうか。複数のバージョンが同時にある事でphpizeの他にphp54izeやphp53ize等があるんだけど、そういう特殊な環境だからなのかな?

$ ls modules/
apc.la  apc.so
$ cp modules/* /virtual/myuser/myhome/local/lib/php54/extensions

仕方ないのでmakeで生成されたファイルをcpでコピー。

extension_dir = "/virtual/myuser/myhome/local/lib/php54/extensions/"
extension=apc.so

この内容でphp.iniを作ってこれでAPCが使えるかと思いきや、前述と同じエラーが出ました。

CGIWrap debuggingを試してみる

Usually, either rename or linkthe script temporarily to a file which ends with .phpdextension, or add a AddType application/x-httpd-phpcgi-debug .phpline to your .htaccess file.

前述のScript Errorをよく読んでみると、デバッグ手段が書いてある事に気がつきました。拡張子を.phpdに変える*1か、MimeTypeをapplication/x-httpd-phpcgi-debugにすると、デバッグ出来るらしい。

AddHandler application/x-httpd-php5cgi .php   #5.2.5
AddHandler application/x-httpd-php53cgi .php #5.3.8
AddHandler application/x-httpd-php54cgi .php #5.4.7

coreserverはこれでphpのバージョンを使い分けます。

AddType application/x-httpd-php5cgi-debug .php
AddType application/x-httpd-php53cgi-debug .php
AddType application/x-httpd-php54cgi-debug .php

試しにやってみたら、デバッグ出来ました。この辺はちゃんとそれぞれ用意してあるみたいです。
ただ、今書いてる最中に気がついたけど、AddHandlerじゃなくてAddTypeを使っちゃってました。でも、ちゃんと指定したバージョンでのデバッグになってたので、このサーバーではどっちで設定しても良い様にしてあるんだと思います。

PHP Warning:  PHP Startup: apc: Unable to initialize module
Module compiled with module API=20060613
PHP    compiled with module API=20100525

デバッグでは、phpの普段意識しない低レイヤー部の動きを表すデバッグ出力が、ブラウザに出てました。その中に、APCモジュールの初期化に失敗しているメッセージがあり、理由としてはphpとAPCモジュールで、コンパイル時に使ったAPI*2のバージョンが違うといったもの。
coreserverに元々あったAPCでも、自分でビルドしたAPCでも、同じ理由で初期化に失敗しているようです。

php54izeの中を見てみた
$ php54ize
Configuring for:
PHP Api Version:         20041225
Zend Module Api No:      20060613
Zend Extension Api No:   220060519

phpizeした時に似たようなものが出ていたので、次はphpizeを調べることに。恐らく「Zend Module Api No」が「20100525」になれば解決出来そうな感じ。

#!/bin/sh

# Variable declaration
prefix='/usr/local'
datarootdir='/usr/local/php'
exec_prefix="`eval echo ${prefix}`"
phpdir="`eval echo ${exec_prefix}/lib/php`/build"
includedir="`eval echo ${prefix}/include`/php"
builddir="`pwd`"
SED="/usr/bin/sed"

[snip]

phpize、ここでは5.4系用のphp54izeだけど、の中身は単にシェルスクリプトみたいなので、中を見てみました。
configureのprefixと同じものか分からないけど、prefix='/usr/local'と決めうちになってたりします。この辺が怪しい様な感じです。

./php54ize_
exec_prefix=/usr/local
phpdir=/usr/local/lib/php/build
includedir=/usr/local/include/php

php54izeをコピーして、変数をechoしてみました。phpdir、includedirとか、異なるバージョンのphpが入ってる環境で、どうなるのか、気になります。

$ ls /usr/local/lib/php/build/
acinclude.m4          config.sub            ltmain.sh             mkdep.awk             run-tests.php         shtool                
config.guess          libtool.m4            Makefile.global       phpize.m4             scan_makefile_in.awk

試しにphpdirの中を確認してみると、どうもビルドに必要そうなファイルが入ってました。

[snip]

phpize_check_build_files()
{
  if test ! -d "$phpdir"; then
    cat <<EOF
Cannot find build files at '$phpdir'. Please check your PHP installation.

EOF
    exit 1
  fi

[snip]

phpizeの中をもう一度見てみると、phpize_check_build_files関数の中でphpdirを参照していて、build filesを探してる的なメッセージもあります。

この辺りから、異なるバージョンのphpを同居させるにあたってphpizeは単に別名で保存しておくだけじゃなく、中で序盤に定義してある変数の書き換えや、phpdirに有るべきビルドファイルも、バージョン毎に残しておく必要が有るんじゃないかと思いました。
この仮定が合っている場合、ビルドに必要なファイルが無いってことになるので、ここで行き詰まりです。

環境

*1:エラーメッセージだと.phpdextensionとなってるけど、多分スペース抜け落ちだと思う。

*2:何のAPIか知らないけど

Accept-Languageを見て言語別に分けるApacheの多言語化をやってみたのでメモ

index.html.jaとかindex.html.enとかでApacheだけで多言語化出来る事は一応知ってたけど、phpとか使わないサイトだけど多言語化はするなんて、今までやった事無かった。たまたま、使えそうな機会があったので、やってみました。

ブラウザかのHTTP RequestにあるAccept-Language headerを見て、言語別に振り分けるんですが、複数の言語を優先度付きで設定できたりen-USといったロケールのサブセットも指定できるので、ちょっと予想しにくい動きをします。
この辺も、色々設定してcurlで確認してみたので書いておきます。というか、こっちを書きたい。

多言語化のやり方

mod_negotiation + mod_mime + FileInfo + Multiviews Options ディレクティブを使った多言語化

いまいち、この方法の名前みたいなのが分からないけど、mod_negotiationが主となる方法っぽい。他のmod_mimeやディレクティブは無くてもやる方法もあるみたい*1だけど、今回は全部セットで使います。
今回は、基本的に日本語のロケールが指定してあれば日本語を、それ以外は英語になる様に設定しました。

コンテントネゴシエーション - Apache HTTP サーバ バージョン 2.2

この機能については、Apacheドキュメントではこのページが詳しい様子。すると、コンテンツネゴシエーションが、この方法の名前ってことになるのかな?なんかしっくりこないけど。

httpd.conf
AllowOverride FileInfo Options=MultiViews

今回は.htaccessに設定を出したので、httpd.confのAllowOverrideに設定します。
後述する.htaccessを、多言語化したいファイルのあるディレクトリに作るけどFileInfoはAddLanguageに、Options=MultiViewsは、そのままMultiViews Optionsディレクティブを使う為に。ちなみにAllowOverride AllだとMultiViewsは上書き可能にならないらしい。

.htaccess
AddLanguage ja-jp-mac  .ja
AddLanguage ja-jp          .ja
AddLanguage ja               .ja
Options +MultiViews

AddLanguageの3行は無くても、大抵はhttpd.confに基本的な設定があるので振り分けはされるけど、あった方が多分意図した振り分けになると思う。本当はen-USやen-GBとかも書いておいた方が良いのかもしれないけど、あまり深追いしたくなかったので、今回は無しにしました。

用意したファイル
  • index.html.ja
  • index.html.en

index.htmlは置いてません。あまりちゃんと確認してないけどindex.htmlも置いてあると、多言語化よりもindex.htmlが優先されているようでした。

挙動の確認

$  curl -v -H 'Accept-Language: ja-JP, en;q=0.8' -I http://example.com

基本的にcurlコマンドを使って挙動を確認しました。

Accept-Languageに複数のロケールがあり、優先度が不明な場合、LanguagePriorityによって決まる。
Accept-Language: ja, en

もっと下に、httpd.confのこれに関連する部分を抜粋してあります。そのhttpd.confと前述の.htaccessが設定してある状態で考えます。
jaとenが指定されているけど優先度が不明。LanguagePriorityではenが最優先なので、index.html.enが出力される。

mod_negotiation - Apache HTTP サーバ バージョン 2.2

AddLanguage ja .jaはAccept-Language: ja-JPとは合致しない

とても不便ですが、ロケール*2のサブセットはサブセット無しのものには合致しないようです。と書いても、かなり分かりにくいと思うので具体例を書きます。

AddLanguage ja .ja
AddLanguage en .en
Accept-Language: ja-JP, en;q=0.8

この例では、AddLanguageがこの2つだけの場合で考えます。AddLanguage ja-JP .jpという設定が無いので、優先度が0.8のenが選択されて、index.html.enが出力されます。前述のやり方でja-JPやja-JP-macを設定してるのは、この為です。

サブセットのあるロケールだけを指定した場合は、希望した言語が選択される場合がある
AddLanguage ja .ja
AddLanguage en .en
Accept-Language: ja-JP

この例でも、AddLanguageがこの2つだけの場合で考えます。AddLanguage ja-JP .jpという設定が無くLanguagePriorityではenが最優先なのでenが選択されると思いきや、jaが選択されます。

AddLanguage ja .ja
AddLanguage en .en
Accept-Language: ja-Foo, ja-Bar

こんな、あり得ないロケールであっても、ロケールがja系のみしか指定されてないなら、LanguagePriorityに関わらずjaが選択されるみたい。

前述の挙動はForceLanguagePriorityの設定による
ForceLanguagePriority Prefer Fallback
#ForceLanguagePriority Prefer
#ForceLanguagePriority Fallback

これはPreferとFallbackの、2つの場合でLanguagePriorityを使うかどうかを設定します。ForceLanguagePriority Prefer Fallbackの場合は、どちらの場合でもLanguagePriorityを使います。

Prefer
優先度の同じロケールが指定されている場合にLanguagePriorityを見て、優先されるロケールを選択する様になる。設定しなければ300 Multiple Choicesが返されます。
Fallback
サーバー側で用意してないロケールを指定した場合にLanguagePriorityを見て、優先されるロケールを選択する様になる。設定しなければ406 Not Acceptableが返されます。

mod_negotiation - Apache HTTP サーバ バージョン 2.2

Apacheドキュメントの挙動について書いてあるところ

コンテントネゴシエーション - Apache HTTP サーバ バージョン 2.2

かなり難しい表現だけど、どういうアルゴリズムでロケール*3が選択されるか、解説してあります。

httpd.confにある設定の抜粋

#
# DefaultLanguage and AddLanguage allows you to specify the language of 
# a document. You can then use content negotiation to give a browser a 
# file in a language the user can understand.
#
# Specify a default language. This means that all data
# going out without a specific language tag (see below) will 
# be marked with this one. You probably do NOT want to set
# this unless you are sure it is correct for all cases.
#
# * It is generally better to not mark a page as 
# * being a certain language than marking it with the wrong
# * language!
#
# DefaultLanguage nl
#
# Note 1: The suffix does not have to be the same as the language
# keyword --- those with documents in Polish (whose net-standard
# language code is pl) may wish to use "AddLanguage pl .po" to
# avoid the ambiguity with the common suffix for perl scripts.
#
# Note 2: The example entries below illustrate that in some cases 
# the two character 'Language' abbreviation is not identical to 
# the two character 'Country' code for its country,
# E.g. 'Danmark/dk' versus 'Danish/da'.
#
# Note 3: In the case of 'ltz' we violate the RFC by using a three char
# specifier. There is 'work in progress' to fix this and get
# the reference data for rfc1766 cleaned up.
#
# Catalan (ca) - Croatian (hr) - Czech (cs) - Danish (da) - Dutch (nl)
# English (en) - Esperanto (eo) - Estonian (et) - French (fr) - German (de)
# Greek-Modern (el) - Hebrew (he) - Italian (it) - Japanese (ja)
# Korean (ko) - Luxembourgeois* (ltz) - Norwegian Nynorsk (nn)
# Norwegian (no) - Polish (pl) - Portugese (pt)
# Brazilian Portuguese (pt-BR) - Russian (ru) - Swedish (sv)
# Simplified Chinese (zh-CN) - Spanish (es) - Traditional Chinese (zh-TW)
#
AddLanguage ca .ca
AddLanguage cs .cz .cs
AddLanguage da .dk
AddLanguage de .de
AddLanguage el .el
AddLanguage en .en
AddLanguage eo .eo
AddLanguage es .es
AddLanguage et .et
AddLanguage fr .fr
AddLanguage he .he
AddLanguage hr .hr
AddLanguage it .it
AddLanguage ja .ja
AddLanguage ko .ko
AddLanguage ltz .ltz
AddLanguage nl .nl
AddLanguage nn .nn
AddLanguage no .no
AddLanguage pl .po
AddLanguage pt .pt
AddLanguage pt-BR .pt-br
AddLanguage ru .ru
AddLanguage sv .sv
AddLanguage zh-CN .zh-cn
AddLanguage zh-TW .zh-tw

#
# LanguagePriority allows you to give precedence to some languages
# in case of a tie during content negotiation.
#
# Just list the languages in decreasing order of preference. We have
# more or less alphabetized them here. You probably want to change this.
#
LanguagePriority en ca cs da de el eo es et fr he hr it ja ko ltz nl nn no pl pt pt-BR ru sv zh-CN zh-TW

#
# ForceLanguagePriority allows you to serve a result page rather than
# MULTIPLE CHOICES (Prefer) [in case of a tie] or NOT ACCEPTABLE (Fallback)
# [in case no accepted languages matched the available variants]
#
ForceLanguagePriority Prefer Fallback

httpd.confはこんな感じで、たぶんCentOSでyumで入れたApacheのままになっていると思います。今気がついたけどDefaultLanguageがコメントアウトされたままで、これをちゃんと設定したら、また挙動変わるのかも。

*1:type-map ファイルを使う

*2:言語タグというらしい

*3:variantと表現されてる

ドコモのAndroid端末にプリインストールされてるらしい邪魔なアプリ

スマートフォンは、それほど真剣に追いかけてないので、たまに見聞きする情報*1からの印象ですが、国産のAndroid端末は大抵地雷だと思っています。それとあわせて、微妙に思わせる情報として入ってくるのが、ドコモのプリインストールアプリが、また電池を食ったり、バグだらけという話。国産端末を持ってないので、今まであまり気にしてなかったけど、ちょっとだけ知っておこうかなと思いました。まぁこれは国産じゃなくてもドコモからなら入ってるわけですが。

ドコモ電話帳サービス

ちょっと検索した感じ、Androidの電話帳とは別にドコモが用意した電話帳がプリインストールされていて、それの事っぽい。アプリ名にサービスってついてるのが紛らわしい感じ。これはかなり電池を無駄食いするらしく、更にドコモのプリインストールアプリを消したり無効化しようとしてる人達からみても、なかなかそれが出来ないゾンビのようなアプリになっているらしい。

imxs開発者ブログ 電話帳サービスとの再戦・その2

http://blog.livedoor.jp/sumahoreview/archives/21332888.html
無効化やアンインストールではないけど、ある程度、ドコモ電話帳サービスの暴走を軽減する方法がある様です。

ドコモバックアップ

ちょっと検索しただけだと、具体的なところが良く分からなかった。「電話帳バックアップ」という名前で機能が変わらないアプリもドコモから出ているらしく、ドコモバックアップとは電話帳のバックアップを提供するものらしい。
ドコモバックアップが電池をすごい消費しているという口コミがそこそこあるので、これもバッテリー食いっぽい。

iコンシェル

ちょっと良く分からないんだけど、どうやらiコンシェルというのはサービス名らしい。そのサービスに対応した端末というのがあるらしく、対応端末にiコンシェルに必要なアプリがプリインストールされているみたい。

たぶん問題点はこんなところ。ちょっと検索しただけだと確認できなかったけど、iコンシェルに未契約なのにプリインストールされた関連アプリが無駄に起動してバッテリーを食うなら、かなりマイナス点だなぁ。

あと、はっきり書いてなかったけどiコンシェル関連アプリって書いてるとこがあったから、恐らく複数のアプリからなるサービスなんだろう。ちょっと探して一覧にしようかとも思ったけど、こういうネガティブ方面ではがんばりたくない。どうせ自分の端末には入ってないし・・・。

ドコモあんしんスキャン

この手のものは、どうしたってリソースを使うしバッテリーも使うから、しょうがない気はする。ちょっと検索したところ中身はマカフィーみたいだし、Google Playでの評価も悪くない。プリインストールかどうかはわかんなかった。

https://play.google.com/store/apps/details?id=com.mcafee.vsm_android_dcm

spモードメール

ここで挙げた中で唯一、自分の端末にプリインストールされてたアプリ。Google Playでもどこでも評判が悪い。
これが出る前は、個人の開発者が作ったIMoNiが使われていたと思う*2けど、ドコモ公式から出たspモードメールがあまりにひど過ぎて、それまで使ってた個人開発のアプリがすごい評価されていた記憶があります。最近のspモードメールが改善してるのかどうかは分からないけど。
あと、アプリ名に半角カタカナを使ってるってだけで、なんか嫌。

どうやら内部でMiniDcmWapPushHelperという別のアプリ(?)を使っているらしい。spモードメールは無効化出来たけど、MiniDcmWapPushHelperは出来ないのは何でだろう。

以下のプリインストールアプリは無効化できません。

  • マーケットからUpdateを行った
  • Intent.CATEGORY_HOMEのActivityを持っている (= Launcher Application)
  • System と同じSignature を持っている ( = System Application)

Disableを選択すると、PackegeManager#setApplicationEnabledSetting()がよばれ無効化されます。

無効化されたアプリは、アプリ一覧に表示されなくなります。

プリインストールアプリの無効化 - baroqueworksdevの日記

プリインストールアプリで無効化できないのはこの3つの条件があるらしいけど、MiniDcmWapPushHelperはGoogle Playには存在してないし、ランチャーでもない。するとやっぱりシステムアプリという位置づけなのかなぁ。
それはそうと、プリインストールアプリをアップデートすると無効化できなくなるって、なんか理不尽な感じがするけど、なんでだろう。

*1:バッテリーがすぐなくなる。通話中に再起動する。通話中じゃなくても再起動する。プリインストールで本体メモリがすでいっぱい。などなど

*2:たぶん。当時Android使ってなかったから良く覚えてない。

bash-completion2だと$BASH_COMPLETION_DIRというシェル変数が無い件

MacPortsで$ sudo port install bash-completionしたら、bash-completionのバージョンが2系になってました。1系から変わった部分も有るらしく、補完はちゃんと動くけどGitとプロンプト変数PS1とbash_completionと - kanonjiの日記でセットしたGItのブランチ名をプロンプトに表示するやつが動かなかったので、調べてみました。

まとめ

$BASH_COMPLETION_DIRが無くなった

$BASH_COMPLETION_DIRというシェル変数がなくなっていて、.bash_profileに書いたif [ -f $BASH_COMPLETION_DIR/git ]; thenというif文が常にfalseになってました。

/opt/local/share/bash-completion/completions/

$BASH_COMPLETION_DIRに代入されていたファイルパスも、基本的には無くなっています。代わりに/opt/local/share/bash-completion/completions/に、各コマンドのcompletionsファイル*1が配置されています。

$ set | grep /opt/local/share/bash-completion/completions/

このファイルパスが代入されたシェル変数は、どうやら無いみたい。

$BASH_COMPLETION_COMPAT_DIR
$ set | grep BASH_COMPLETION_COMPAT_DIR
BASH_COMPLETION_COMPAT_DIR=/opt/local/etc/bash_completion.d

$BASH_COMPLETION_DIRに代入されていたファイルパスは、互換用のシェル変数っぽい名前の$BASH_COMPLETION_COMPAT_DIRに代入されています。今回の環境では1系のbash-completionが元々入って無かったので/opt/local/etc/bash_completion.dは存在しませんでした。

__git_ps1等が別ファイルになった

# 3) Consider changing your PS1 to also show the current branch,
# see git-prompt.sh for details.

https://github.com/git/git/blob/v1.8.0/contrib/completion/git-completion.bash

https://github.com/git/git/blob/v1.8.0/contrib/completion/git-prompt.sh

1.8.0からなのか、もう少し前からなのか分からないけど、PS1環境変数を使ってプロンプトにgitのブランチ名を出すのに必要なコードは、別ファイルに切り出されている様子。

$ vim .profile #.bash_profile や .bashrcでも環境に合わせて
# bash_completion.d/git
if [ -f $BASH_COMPLETION_DIR/git ]; then
    export PS1='\[\033[01;32m\]\u@\h\[\033[01;33m\] \w$(__git_ps1) \n\[\033[01;34m\]\$\[\033[00m\] '
else
    export PS1='\[\e]0;\w\a\]\n\[\e[32m\]\u@\h \[\e[33m\]\w\[\e[0m\]\n\$ '
fi
Gitとプロンプト変数PS1とbash_completionと - kanonjiの日記
$ vim .profile #.bash_profile や .bashrcでも環境に合わせて
# bash-prompt
if [ -f /opt/local/share/git-core/git-prompt.sh ]; then
    . /opt/local/share/git-core/git-prompt.sh
    export PS1='\[\033[01;32m\]\u@\h\[\033[01;33m\] \w$(__git_ps1) \n\[\033[01;34m\]\$\[\033[00m\] '
else
    export PS1='\[\e]0;\w\a\]\n\[\e[32m\]\u@\h \[\e[33m\]\w\[\e[0m\]\n\$ '
fi

こんな感じで取り急ぎ動く様にしました。

補足と余談

MacPortsにあるbash-completionのセットアップ手順

howto/bash-completion – MacPorts

MacPortsのWikiにセットアップ手順が解説されています。Mac標準のbash 3.2ではbash-completion 2系が動かないのでbash 4.1以上を設定したり、.bash_profileに書く設定が載ってます。

MacPortsでパッケージをインストールする際、常に+bash_completion variantsを指定する
$ sudo vi /opt/local/etc/macports/variants.conf

+bash_completion

このファイルに、常に使いたいvariantsを設定出来るみたいです。

.bash_profileから読み込むファイル
$ ls -al /opt/local/etc/bash_completion 
lrwxr-xr-x  1 root  admin  43  7  6 07:17 /opt/local/etc/bash_completion -> /opt/local/etc/profile.d/bash_completion.sh

この様にシンボリックリンクが貼ってあります。

/opt/local/etc/bash_completion内から/opt/local/share/bash-completion/bash_completionが呼ばれています。この中で、前述の$BASH_COMPLETION_COMPAT_DIRが定義されてたりします。

環境

Mac Mac OS X 10.7.4(Lion)
git-core @1.8.0_0+bash_completion+credential_osxkeychain+doc+pcre+python27
bash-completion @2.0_1

書いた日

2012-11-21
ちょっとほっといたけどそんなに日は経ってない。

*1:と呼んでいいのか分からないけど

Thunderbirdのkeyconfig拡張を入れて暴発するアーカイブなどのショートカットキーを無効にした

メーラーにはそんなにこだわりもないので、無難にThunderbirdを使ってるんですが、どうしても変えたい設定がありました。

A メールをアーカイブ
S スターをつける
J 迷惑メール扱いにする

この3つだけじゃないですが、CtrlやAlt無しの単体で使えるショートカットキーが10個くらいあります。これフォーカスがThunderbirdに向いてる事に気がつかずに、何か入力しようとして、意図せずこのショートカットを使ってしまうことがあってちょっと危ない。メールを大量に捌く人は便利に使っているかもしれないけど、使わない自分にとっては不意に動いてしまう危険なショートカットでしかない。という事で、また意図せずアーカイブ送りにしてしまったので、いい加減対策しました。

Keyconfigæ‹¡å¼µ

  1. http://mozilla.dorando.at/keyconfig.xpi からダウンロード
  2. ツール > アドオン > ファイルからアドオンをインストール... > keyconfig.xpiを選択
  3. 再起動
  4. ツール > キーボードショートカットのカスタマイズ...

出てきたダイアログで、CtrlやAlt無しのショートカットを探してキーを削除していけば、危険なショートカットを無効にできます。

補足

どういうわけかこのkeyconfig拡張はThunderbird向けアドオンに置いてありません。

キーボードショートカットのカスタマイズ

Keyconfig 拡張 でキーボードショートカットの設定ができます (ただし、サードパーティ製の拡張機能は、Mozilla によるサポートや保証がありません)。

https://support.mozillamessaging.com/ja/kb/keyboard-shortcuts#w_agckcuckcoaicdckcnaecccnagaeaialczacaj

じゃあ、なにか非公式なものかというと、Mozillaのヘルプでも紹介されているものです。公式というわけでもなく dorando というユーザーが作成したアドオンのようです。

XPIファイルへのリンクまでに、ヘルプ、Mozillazineのknowlege base、フォーラムと辿らないといけないという、ものすごいユーザーアンフレンドリーな状態ですが、Thunderbird向けアドオンに置かないのは何か理由があるんだろうか・・・

環境

Mac Mac OS X 10.5.8(Leopard)
Thunderbird 16.0.2
Keyconfig 20110522

Mac Leopardでnode-v0.8.7をビルド出来た

node 0.6.xはLeopardでもビルド出来てたんだけど、次の安定版0.8.xになってからビルド出来ずに困ってました。Mac Leopardにnode-v0.8.1.pkgで入れたnodeをアンインストールする - kanonjiの日記でインストーラーを使ってみると、インストールディレクトリが固定であまり好みじゃなく、タイトル通り消してしまった。

解決策

$ CC=gcc-4.2 CXX=g++-4.2 nvm install v0.8.7

これでビルド出来ました。

CC=gcc-4.2 CXX=g++-4.2 ./configure && make
Fix issues building node 0.6.15 on OS X 10.5 · Issue #3114 · nodejs/node-v0.x-archive · GitHub

Leopardのデフォルトのgccだとビルド出来ず、gcc 4.2を使う必要があるとの事。nvmで入れてるけど、nvmでも上記の通りビルド出来ました。

補足

0.8.7のビルド出来たけど、対話モードがエラーする
$ nvm use v0.8.7
Now using node v0.8.7
$ node
> Assertion failed: (!!(events & UV__IO_READ) ^ !!(events & UV__IO_WRITE)), function uv__stream_io, file ../deps/uv/src/unix/stream.c, line 732.

ビルド出来たのは良いけど、対話モードで起動しようとするとエラーになりました。

`node < /dev/tty` doesn't seem to work as expected on OSX · Issue #3072 · nodejs/node-v0.x-archive · GitHubのissueで直したり直ってないってコメントが来たりで、対応中の様子。

$ sudo node web.js

ちょうど書いてるコードは、動かしてみたら動くみたいなので、対話モードだけ使えないのなら、まぁそんなに不都合は無いかな。

デフォルトのgccを使った場合のエラー
$ ./configure --prefix=/Users/myuser/tmp/node-v0.8.6
$ make
[長くビルド処理が進み・・・]
  LD_LIBRARY_PATH=/Users/myuser/tmp/node-v0.8.6/out/Release/lib.host:/Users/myuser/tmp/node-v0.8.6/out/Release/lib.target:$LD_LIBRARY_PATH; export LD_LIBRARY_PATH; cd ../deps/v8/tools/gyp; mkdir -p /Users/myuser/tmp/node-v0.8.6/out/Release/obj.target/v8_snapshot/geni; "/Users/myuser/tmp/node-v0.8.6/out/Release/mksnapshot" --log-snapshot-positions --logfile "/Users/myuser/tmp/node-v0.8.6/out/Release/obj.target/v8_snapshot/geni/snapshot.log" "/Users/myuser/tmp/node-v0.8.6/out/Release/obj.target/v8_snapshot/geni/snapshot.cc"
/bin/sh: line 1: 63221 Bus error               "/Users/myuser/tmp/node-v0.8.6/out/Release/mksnapshot" --log-snapshot-positions --logfile "/Users/myuser/tmp/node-v0.8.6/out/Release/obj.target/v8_snapshot/geni/snapshot.log" "/Users/myuser/tmp/node-v0.8.6/out/Release/obj.target/v8_snapshot/geni/snapshot.cc"
make[1]: *** [/Users/myuser/tmp/node-v0.8.6/out/Release/obj.target/v8_snapshot/geni/snapshot.cc] Error 138
make: *** [node] Error 2

こんなエラーになりました。なんどかビルドは試していて、上記にsnapshot.logに色々書いてあったケースもあったような気がするんだけど、今回は空っぽでした。なんでだろう。

LeopardはPythonのバージョンもデフォルトだと合わない

python 2.6 or 2.7. The build tools distributed with Node run on python.

Installation · nodejs/node-v0.x-archive Wiki · GitHub

pythonもLeopardのデフォルトが2.5系なので、もう1個新しいバージョンを入れる必要があります。

環境

Mac Mac OS X 10.5.8(Leopard)
node 0.8.7
Python 2.7.2

書いた日

2012-08-16
例によって下書きのまま放置してた