ラベル command line の投稿を表示しています。 すべての投稿を表示
ラベル command line の投稿を表示しています。 すべての投稿を表示

2013年7月21日日曜日

fileコマンドがテキストファイルでエラーになる問題の回避

昨日、WindowsやLinuxで作成したテキストファイルの文字コーディングを調べようとしたら、fileコマンド( /usr/bin/file )でエラーがでました。
fileコマンドは、ファイルの音声や画像などの種類や、テキストファイルの場合文字エンコーディングなどを表示してくれるコマンドです。
やりたかったのは、UTF-8以外のファイルを探して、必要ならばUTF-8に変換しようと思ったのですが。

例えば以下の内容のファイル(UTF-8)をfileコマンドで調べると、ERRORとなります。(OS X 10.8.4)


$ cat test.txt
- 外部キー
  他のテーブルの主キーとなるキー
  外部キーは表の結合に用いる
od -c -t x1 test.txt
0000000    -      外  **  **  部  **  **  キ  **  **  ー  **  **  \n    
           2d  20  e5  a4  96  e9  83  a8  e3  82  ad  e3  83  bc  0a  20
0000020       他  **  **  の  **  **  テ  **  **  ー  **  **  ブ  **  **
           20  e4  bb  96  e3  81  ae  e3  83  86  e3  83  bc  e3  83  96
0000040   ル  **  **  の  **  **  主  **  **  キ  **  **  ー  **  **  と
           e3  83  ab  e3  81  ae  e4  b8  bb  e3  82  ad  e3  83  bc  e3
0000060   **  **  な  **  **  る  **  **  キ  **  **  ー  **  **  \n    
           81  a8  e3  81  aa  e3  82  8b  e3  82  ad  e3  83  bc  0a  20
0000100       外  **  **  部  **  **  キ  **  **  ー  **  **  は  **  **
           20  e5  a4  96  e9  83  a8  e3  82  ad  e3  83  bc  e3  81  af
0000120   表  **  **  の  **  **  結  **  **  合  **  **  に  **  **  用
           e8  a1  a8  e3  81  ae  e7  b5  90  e5  90  88  e3  81  ab  e7
0000140   **  **  い  **  **  る  **  **  \n                            
           94  a8  e3  81  84  e3  82  8b  0a                            
0000151
$ file test.txt
test.txt: ERROR: line 22: regexec error 17, (illegal byte sequence)

fileコマンドで、regexec関数を呼び出していて、その関数が不正なバイトの並びを見つけたというエラーのようです。test.txtは3行しかありませんので、行番号の22は、コマンドかライブラリのソースコードの行番号でしょう。
以前は、このようなエラーを見たことがなかったのですが、いつから出るようになったのでしょうか。

いろいろ試行錯誤したところ、localeの環境変数(LANGなど)を消すかCにすると正常に表示されるようになりました。

echo $LANG
ja_JP.UTF-8
$ LANG=C file test.txt
test.txt: UTF-8 Unicode text
$ unset LANG
$ file test.txt
test.txt: UTF-8 Unicode text

あまり、めでたしめでたしではないですが、暫定的には解決できました。

2012年9月22日土曜日

ターミナルから無圧縮ZIPファイルを作る

少し前の記事で、Automatorでシェルスクリプトを実行するという内容の記事がありましたが、無圧縮ZIPファイルをどのようなコマンドで作っているか書いていませんでした。その記事へのアクセスが結構多いようですので、実際にZIPファイルを作っている部分を書いてみます。エラーチェック等は省略して、肝心の部分は以下のような感じになっています。

zip -r -n ".jpg:.JPG:.jpeg:.JPEG:.gif:.GIF" "$zipf" "$zipd" -x ".DS_Store"

-r オプションは、ZIPの入力ファイルにディレクトリがある場合、再帰的にたどっていくことを指示します。
-n オプションは、引数として与えられた拡張子を持つファイルを、圧縮しないように指示します。tiffやpngも入れてもいいかもしれません。大文字小文字の違いを無視できればよいのですが、ちょっと冗長になっています。私は、テキストファイルなどは圧縮したいので、このオプションを使っています。
-nオプションの代わりに、-0オプションを使えばすべてのファイルが無圧縮になります。-# (#は0から9の数字が入ります)の形式のオプションは、圧縮スピードを相対的に指定するのですが、-0は無圧縮の指定になっています。-0の方が無圧縮ファイル作成の目的に合う人はこちらの方がよいと思います。
$zipfは、作成するZIPファイル名が入った変数です。
$zipdは、作成対象のディレクトリ名が入った変数です。両方共ダブルクォーテーションで囲んであるのは、文字列中にスペースがあるとシェルが別々の引数として処理するため、予防的に入れています。
最後の-xオプションは、ZIPの対象としないファイルを指定します。.DS_StoreはFinderが不可視ファイルとして作る場合がありますが、今回はZIPファイルに含める必要はないため除外するようにしています。

zipコマンドの詳細はターミナルからmanコマンドで調べることもできます。

2012年9月15日土曜日

Finderの「このアプリケーションで開く」その3

一応、表題の問題は解決はしたのですが、前回からの続きです。
The Unarchiver以外にも、複数回登録されているアプリケーションがないか、確認してみました。
前回と同じく、lsregisterのあるディレクトリに移動します。

$ cd `dirname \`locate lsregister\``

次のコマンドをターミナルから入れて確認します。

$ ./lsregister -dump | grep "path: .*\.app" | sort | uniq -d


各コマンドの説明をします。
lsregisterの -dump オプションで、Lauch Servicesが使っているデータベースを出力して次のgrepコマンドに渡します。
grepコマンドは、渡された文字列から条件に合う行を探して表示します。ここでは、渡された各行に、path:で始まり.appで終わるパターンがあるかどうかを探しています。path: 〜 .appは行の途中に出てきていてもかまいません。次に、sortコマンドに見つかった結果を渡します。
sortコマンドは、入力された行を順番に(今回の場合アルファベット順)に並び替えて表示します。その結果をuniqコマンドに渡します。
uniqコマンドは、入力から重複している行を探してくれます。uniqコマンドは隣同士の行(1行前の行と現在の行)しか比較しませんので、uniqにgrepの結果を渡す前にsortコマンドで順番に並び替えています。同じ行があれば隣同士になります。uniqコマンドの-dオプションは、重複している行だけを表示します。

結果は次のようになりました。

path:      /Volumes/Disk2/Applications/Flaex.app
path:      /Volumes/Disk2/Applications/GrowlTunes.app
path:      /Volumes/Disk2/Applications/Inkscape.app
path:      /Volumes/Disk2/Applications/OnyX.app
path:      /Volumes/Disk2/Applications/OpenOffice.org.app
path:      /Volumes/Disk2/Applications/Rember.app

同じパスで重複登録されているアプリケーションが6個ありました。あまり使っていないものばかりだったので、今回はそのままにすることにしました。
ところで、今のままですと、例えば起動ディスクと外付けディスクに同じアプリケーションがある場合見つかりません。これは、時間があればスクリプトでも作ってみようかと思います。