sort の並び順

会社の製品の性能検証を行うことになり、データセンターに行ってきた。

問題は、検証環境を構築し、テストデータをリストアした時に発生した。
テストデータのチェックを行ったところ、破損が確認されたのだ。

ちなみに、テストデータの破損チェックは、以下のような手順で行った。

1. テストデータの各ファイルの md5 チェックサムを取得し、
md5.txt というテキストファイルに書き出すスクリプトを作成
　　（スクリプトの内容は、読み飛ばしてもらって結構です。）

#! /bin/bash

# find /test_data -type f | sort > /tmp/data_files

# while read file
> do
> openssl dgst -md5 file >> md5.txt
> done < /tmp/data_files

2. テストデータ作成環境で上記スクリプトを実行し、
md5.txt を md5.txt.org という名前に変更

3. 検証環境で上記スクリプトを実行

4. テストデータ作成環境で取得した md5.txt.org と
検証環境で取得した md5.txt を比較する

# diff /tmp/md5.txt.org /tmp/md5.txt

ところが、良く調べてみると手順 1 で作成したスクリプトにバグが有ったらしい。
スクリプトの結果作成される md5 チェックサムを書き出したテキストファイルが、
環境に依存するようだ。

環境依存するのは、スクリプト中の以下の行にある、"sort" コマンドだ。

# find /test_data -type f | sort > /tmp/data_files

"sort" コマンドをオプション無しで実行すると、標準入力の内容を
辞書順に並べかえて標準出力に書き出す。

問題は、この "辞書順" が環境によって異なることだ。
例えば、私のテスト環境では "A" の方が "a" より先だったが、
先輩の環境では逆だった。

man コマンドには、特筆するべき事は書いていない。
特に、"辞書順" を規程するオプションも見当たらなかった。

途方にくれて、google 検索をしてみると、以下のページが見つかった。


要約すると、"sort" の結果は環境変数によって異なるとのこと。
"sort" 実行時には、

　　"LC_ALL=C sort"

とすれば、環境に依らず一定の結果が得られるらしい。
（上記コマンドは "sort" 実行時のみ、環境変数 "LC_ALL" を "C" にする）

寡聞にして "LC_ALL" という環境変数は知らなかったが、
取り合えず実行すると、私の環境でも先輩の環境でも "A" の方が "a" よりも
先にくるようになった。

しかし、まだ問題は残っていた。
"."　や "_" の表示順が異なるのだ。

エンジニアとして、ここは sort の実行順を詳細に調査するべきだが、
あいにくと時間が無い。

とりあえず、

"LANG=C sort"

にしたら全て上手く言った。
でも、後学のために、いつか調査をした方がよいな。。

emacs vs vim

新入社員が大量に入社した今日この頃、技術系志望の人には開発本部長より
「vim か emacs のどちらかを使えるように」というありがたいお言葉が
あったそうだ。

私はというと、vim も emacs も両方使用する。
それが、新入社員には珍しいらしく、
「どっちが良いでしょうか？」という質問をされた。

「好きな方にすれば」というのが本音なのだが、「怖い先輩」と
言われたくないので、真面目に答えてしまった。

SE である私の立場では、vi は最低限使用出来る必要がある。
共有のマシンや検証環境でもは必ず入っているのは vi だ。

さらに言うと、普段、vim を自己流にカスタマイズをしていると、
思わぬ入力ミスをしてしまうかもしれない。
サーバーでやってしまうと、シャレにならない可能性がある。
実は要注意！

逆に、vi を最低限使用できれば、他はどうでも良い。
（ちなみに、「最低限」とは、
`h',`j',`k',`l' を用いた移動、検索、編集くらい）


まあ、自分の場合、次のように使いわけているかな。
1. 閲覧専用時は vim
左手の小指が痛くならない。

2. ログの確認時は vim
ログのように大きいファイルは emacs では開けない。

3. 日本語の混じったメモをとる時は emacs
vim の場合、半角入力にしないとコマンドを認識しない。
emacs ならば、日本語入力モードでもコマンドを実行出来る

4. その他、理由がなければ emacs
前述のように、カスタマイズした vi に慣れすぎると
泣きを見る可能性がある。
でも、エディタを自己流にカスタマイズすることは大切
（生産性に係わる）

まあ、結局の所、vi と emacs なんて、宗教の問題と同じだと思うけど。

NFS は誰の物？

Linux で環境を構築したお客様から、「nfsマウントがうまくできない」という
お問い合わせをいただいた。
どうやら、聞いてみると nfs マウントしたディレクトリ内で読み書きが
出来ないらしい。

mount コマンドでは、確かに nfs マウントが出来ている模様。
アクセス権も、問題なさそう。
でも、`ls' を実行しても、中のディレクトリが見れないという。

こういう時は、大体お客様が何か勘違いをしている。
「そんな事あるわけないだろう」と思いつつ調べてみた。

Linux のユーザーは、内部的には UID (user id の略だと思う)で判別されている。
User1 というユーザーをオーナーとしても、システム内では User1 の UID で
管理している。
ローカルのファイルやディレクトリのアクセス権を管理する分には問題ない。

しかし、nfs のようにネットワークごしにアクセスする場合、nfs ホストで
User1 にアクセス権を与え、nfs クライアントの User1 でアクセスしても
ホストとクライアントで User1 の UID が異なれば、OS からは別のユーザーから
アクセスしているように見える。

調べた所、今回の現象は、ホストとクライアントで UID が異なっていたために
発生していた。

トラブル解決後、先輩には「常識だろ」と言われたが、正直知らなかった。

弊社のマニュアルには UID の事など書いていない。
（手順通りに普通に構築したら UID は同じになるはずなのだが。）
お客様、疑ってごめんなさい。