UNIX的なアレ

UNIX的なこととかいろいろ

"シェルスクリプトをはじめて書くときに知っておきたいこと"へのコメントまとめ

自分も知らなかったこと等もあり、大変参考になるコメントをありがとうございました。
コメント数がかなり多数になってきたのでこのエントリーでまとめてみたいと思います。(まとめというほど大したものではありませんが。。)

[ (test) コマンドについて

以下のようなコメントをいただきました。

正確には覚えていないですが、[ ] はbashではつかるけど、本当の素のshでは使えなかったと思います。なので、[ ]を使うぐらいなら、/bin/bashと書いては。

id:silverwireさんが、いろいろなOSで調べてくれました。AIXやHP-UXの環境は自分の環境になかったので大変勉強になりました。

id:silverwireさん
ちょっと興味が湧いたので、以下の二つを調べてみました。

1. Bourne Shellで[ を使用できないことってあるのか?
2. testという名前のシェルスクリプトを実行するとどうなるか?

一つめ。

[ (test)がBourne Shell自体に組み込まれていれば、使えないこと
は無いはず。そこで、AIX, FreeBSD, HP-UX, Linux (Red Hat系),
SolarisでBourne Shellを使って調査。

  • AIX 5.1, 5.2, 5.3

[ もtestもシェルビルトイン。外部コマンドは /usr/bin/testが
存在。

[ もtestもシェルビルトイン。外部コマンドは
/bin/[, test
/usr/compat/linux/usr/bin/[, test
が存在。

  • HP-UX 11.00, 11.11, 11.23

[ もtestもシェルビルトイン。
外部コマンドは /usr/bin/testが存在。

[ もtestもシェルビルトイン。
外部コマンドは /usr/bin/testが存在。

  • SunOS 5.5.1, 5.6, 5.7, 5.8, 5.9, 5,10

[ もtestもシェルビルトイン。
外部コマンドは/usr/bin/test, /usr/ucb/testが存在。
これに加え、 5.9と5,10は/usr/xpg4/bin/testも存在。

ということで、よほど初期のUnixで限り、Bourne Shellで[ が使え
ないという心配は無いと思います。

id:bitmapさんもすばらしい意見を書いていただきました。

id:bitmap さん
[ ですが、少なくとも’９６の頃から使えています。
私が始めて触った SunOS 4.x の頃のはずで、この頃から使えてた記憶です。
ただし、test への ln -s だったかは確かではありません。

個人的見解。
一番最初の BourneShell は [ コマンドが「ビルドインではない」は確かに正しいのですが、外部コマンドとして用意されていれば問題ないので同時に /usr/bin/[ というコマンドが普及していなかったと言えないのであれば、このままで問題ないと思われます。で、これについては前述の通り、技術系の本に載っていることから「普及していない」というのは、もっとさかのぼらないと言えないかと思われます。

それから手元で触れるマシンをチェックしたところ
SunOS5.8 : BourneShell（補完もヒストリも無い漢仕様） 、 ビルドイン、[ コマンドは無し
Vine 3.1：bash ソフトリンク、ビルドイン、/usr/bin/[ あり /usr/bin/test ソフトリンク
SuSE Linux 10.2 : bash ソフトリンク、ビルドイン、/usr/bin/[ あり、/usr/bin/test とは別の様子（ファイルサイズ違い）
NetBSD 2.0 : BourneShell (詳細は他人のマシンなので調べてない、ksh が別にありだが完全に別プログラム)、ビルドイン、/bin/[ あり、/bin/test ハードリンク
という結果でした。

なるほど、少なくとも現状では[に関していえば問題なく使用はできるようです。しかしながら、過去にはビルドインコマンドではなかった時代もあったようです。（正式にソースコードを読んだわけではないので断言はできませんが）
似たような議論も過去に2chであったようです。
2ch

testというファイル名について

Unixではtestというファイル名は使用しない、というのが流儀とのことです。
これに関してのポイント、testに限らずコマンド名と重複するファイルは生成しないということですね。まぁ、lsとかrmというファイル名をつくる人はいないでしょうか・・・
たしかにハマるポイントになりがちなので、安易にtestというファイルは生成しないほうが身のためのようです。

LockFile の生成について

これに関してはあまりにもシンプルすぎる記述だったことを反省しております。
こちらに関してもさまざまなご意見をいただきましたが、以下のような手法がありました。

id:hirono さん
Lockファイル作成例は確かに単純すぎて危険。。
チェック＆作成を同時に行うためにmkdirやlnでLockファイルを作るのが普通だし。

id:talas さん
ロックは、test -fした後、touchするまでの間に別のプロセスが同じファイルをopen()とかcreat()してしまってると、ロックにならないという…。
やっぱり、hironoさんがおっしゃっているlnに直してたほうが良いと思います。

やはりmkdir か シムリンクを作成することでtrapさせるというのが主流でしょうか。

たくさんのご意見ありがとうございました

自分の足りない知識、あまりにも簡略化した記述に関してたくさんのツッコミありがとうございました。いままで自分が知らなかった知識もあり大変勉強になったと思っております。
今回のようにいろいろなエンジニアの方から貴重な意見をいただける場として、今後も本blogを続けていきたいと思います。