（Linux等の）シェルスクリプトを Mac の Finder からダブルクリックで実行するには

少し躓いたので、メモメモ。まとめると次の３点が要点となる。

1. スクリプトの拡張子を .command にする
2. ターミナルから、chmod で実行権限を与える
3. スクリプトの Shebang のすぐ下に cd `dirname $0` を入れる （シングルではなくバッククオートであることに注意）

詳細について。まず、シェルスクリプトの書き方から。これは Linux と同様 Shebang ではじめ、通常通りコードを書いていく。

#!/bin/sh

[ここからコード]

このスクリプトファイルをダブルクリックした時にターミナルを起動するように設定する必要がある。Mac 上で拡張子の関連付けを行えばよいことになるが、10.6 (Snow Leopard) では、デフォルトで ".command" という拡張子がターミナルに関連付けられいることを確認した。"install.command" のような感じで拡張子をつけて保存するとよい。（もちろん別の拡張子を利用したい場合はその拡張子をターミナルに関連付けておく）

また、Linux と同様にスクリプトには実行権限を付加しておく必要がある。これは Mac 標準の Finder からは設定できないようなので、ターミナルから実行権限を付加する。例えばコードが install.command だった場合、

chmod +x install.command

もちろん、ファイルがホームディレクトリに無い場合は、該当のディレクトリに移動するか、フルパス指定で実行。

ただし、Mac ではダブルクリックで起動した場合、ホームディレクトリをカレントディレクトリとしてコードが実行されてしまう。例えば、ユーザー名が hoge、コードが /Users/hoge/abc/install.command においてある場合、Mac は自動的にホームディレクトリでコードを実行してしまう（下の太字の部分が Mac が実際に実行しているコマンド）。

Last login Sun Oct 10 22:54:02 on Console
pcname:~ hoge$ /Users/hoge/abc/install.command ; exit;
[コマンド実行結果]
logout

[プロセスが完了しました]

コード内で相対パスを利用している場合、コードの置いてあるディレクトリにカレントディレクトリを移動させないと不具合が出る場合がある。これを行うためには、例えば "cd `dirname $0`" というコードをシェルスクリプトの冒頭に入れておけばいい（シングルではなくバッククオートであることに注意）。これは、コードのパスからディレクトリを dirname で取得し、その結果を cd に渡すことでカレントディレクトリを適切なところに移動するコードである。

結局、スクリプトは次のように書けばよいことになる。

#!/bin/sh
cd `dirname $0`

[ここからコード]

Mac で圧縮された zip ファイルを Ubuntu で解凍した場合のファイル名文字コード修正

Mac で圧縮された zip ファイルを Ubuntu で解凍すると、ファイル名にこちらのページで書いた NFC/NFD の濁点と半濁点の問題が発生してしまいました。

そこでツールを使って修正する方法を見つけました。convmv というツールを用います。ツールのインストールは Ubuntu では非常に簡単ですね。

% apt-get update
% apt-get install convmv

インストールしてよいか聞かれる場合があります。インストール後、次のコマンドを実行すると変換されるファイルを確認することができます。

% convmv -r -f utf8 -t utf8 --nfc [dir]

これはテストだけなので、確認後 -notest オプションを付け加えることで実際に変換します。

% convmv -r -f utf8 -t utf8 --nfc [dir] --notest

以上です。

ＯＳ間の文字コード互換性（Win, Mac, Linux）

最近 Mac を使い始めたのもあって、Win と Linux 間だけでなく Mac も含めてＯＳ間の互換性を調べていましたが、文字コードについてはそれぞれが微妙に違うものを採用していたりして、本当に面倒くさいことがわかりました。今回はこのあたりをちょっとまとめてみます。

（Mac で圧縮した zip ファイルを Ubuntu で解凍した際のファイル名の文字コード問題を修正する機会があったので、その方法をこちらのページに載せておきました）

ＯＳ	文字コード	改行コード
Windows	基本は CP932（Shift-JIS に Microsoft の独自仕様を足したもの）、最近は UTF-8・UTF-16 も。 カーネルや .NET 内部は UTF-16 と思われる	CR+LF
Linux	システムに依るが、主に UTF-8、EUC-JP 等	LF
旧 Mac	MacJapanese （Shift-JIS に Apple の独自仕様を足したもの）	CR
Mac OS X	アプリケーションは MacJapanese カーネルはおそらく UTF-8 か UTF-16 ファイルシステムは UTF-16 NFD（Mac 独自）	LF

※Mac は詳しくないのですが、全て 10.5 (Leopard) で確認しています

このようにしてみると、一般的なものにちょっと独自仕様を足したものが目に付きますね。Mac も Win も、Shift-JIS を基本にしているのでお互いにデータのやり取りはできますが、例えば Mac で作成した標準テキストを Win に持っていくと、文字は読めますが改行コードが LF と CR+LF で異なるために改行がバグります。また、一部のお互いの独自仕様が絡む文字が含まれるとやり取りができなくなる可能性があります。

Mac に関しては非常に汚いですね。Mac OS X までは Shift-JIS を独自拡張した MacJapanese ベースに改行コードとして CR を使ってましたが、Mac OS X からは UNIX ベースになったため改行コードが LF に変わっています。さらに、OS X のシステムも MacJapanese をデフォルトのエンコーディングとしながら、内部的には UTF-8 を利用し、ファイルシステム（HFS+）に NFD 正規化方式を利用した UTF-16 と全部で３種類利用しているようです。

正規化方式の話が出ましたが、「UTF-8」等と書くとほとんどが一般的な NFC 正規化方式を意味し、NFD 方式は Mac ぐらいでしか利用されていません。NFC は濁点や半濁点、ドイツ語等に見られるウムラウトの文字を含めて一字とするのに対して、NFD は「が」→「か」＋「゛」のように分離して表現します。Windows や Linux では NFD に対応しているソフトは少なく、トラブルの原因になりかねません。つまり、濁点や半濁点を含むファイル名を直接テキスト等に書き出すと NFD として書き出され、一般的な UTF エディタ等では開けなくなったり、バグったりします。なので、例えばターミナルから

% ls > dirindex.txt

として書き出すと、UTF-8 NFD（UTF-8-MAC というやつです）で書き出されてしまい、Windows の UTF 対応エディタから開いた場合エラーとなる場合があります。一方で、Mac のテキストエディットでは UTF-8-MAC の文字も UTF-8 のファイルとして読み込めば問題なく表示され、どちらかを意識することなく編集できます。逆に言うと、そこに NFD が混じっていても全く区別がつかないので、Win 等に持っていく場合は注意が必要です。（ちなみに、UTF-8-MAC のテキストを開き、NFD の部分を消して同じ文字を打ち直すとその部分だけ NFC になりました）

ただ、Mac・Linux 間はどちらも UNIX ベースということもあって、Mac のデフォルトエンコーディングの MacJapanese を UTF-8 として、かつ日本語のファイル名を利用しなければ、UTF-8 ベースの Linux ディストリビューションと文字コードに関して完全互換になりそうですね。

しかし、様々な文字コードにソフトを対応させたり文字化け解消や適宜変換をしたりと、世界中でかなりの労力が裂かれてると思うのですが、いい加減統一する方向に向かないんですかね。システムの肥大化や文字化け等のトラブル、ＯＳ間の受け渡しコストとか、統一してしまえば全部解決する気がするんだけどなぁ…。UTF は全世界の文字をほぼ全部表現できることを目指してるので、もう素直に全部 UTF-8 あたりに統一すればいいのに。

…まぁ、色々と大人の事情があるんでしょうね。