シェルスクリプト文法の互換性について

Question

具体的な課題のない質問で済みません。

皆さんがシェルスクリプトを(とりわけ業務で)書くとき、文法の互換性とか移植性ってどの程度気にされていますでしょうか。
典型的な例としては、昔は数値計算はexprコマンドでやっていたのを、今のbashなら"i=$((i+1))"と書けるといったところでしょうか。

私の経験の話として、Linuxのbash前提で作ったシェルスクリプトをBSDベースのアプライアンス機に移植したところ、それにはshしかなくて丸々作り直したということがあり、それ以来シェルスクリプトはどんなUnix/Linux系OSでも極力修正なしに動かせるように書くようにしています。
(bash向けスクリプトを書いている時点で、おじさんだからなのか「何か気持ち悪いなぁ」と思っていたところ、後になって動かない環境があることが発覚して「それ見たことか」と思ったりしたのですが)

今のbashなら配列が簡単に扱えるといったように、やはり新しい文法の方がメリットが大きいとも思うのですが、互換性を意識する場面もなくはないのかと思っています。
その辺の使い分けや考え方についてご意見を聞かせていただけないでしょうか。
特に業界歴の長い、「昔のUnixで育ってきた」という方のご意見があるとうれしいです。

Answer 1

互換性 (というか可搬性) といってもどれだけ担保できるのか疑問です。私は、シェルスクリプトは基本的に環境固有のものだと思っています (ちなみに、BSDにbashが入っていないことは不思議ではないです)。

実際、bashらしさを極力排除して書いたつもりなのにash (dash) で動かなかったりします。また、外部コマンドがなければシェルスクリプトは成り立たないですが、BSD makeでないと動かないとか逆にそのせいで動かないとか、tarのzオプションやfindの-print0オプションをUnixで必ず使えると思うなよとか、psの出力フォーマットでOS当てクイズができそうだとか、うちのechoには-nオプションなどというものはない、とか……。最初にすべてを予見することは不可能です。あとおまけですが、この前「リプレースで運用のシェルスクリプトが動かなくなった」と言われて見てみたら、Cシェルのスクリプトでした。Bourne Shell系でさえないのでbashで動くはずもなく、tcshをインストールして一件落着。

私は、可搬性を気にするのはconfigureスクリプトを作るときだけです (それも、適当なm4マクロがないときだけ)。このへんを見てがんばります。

Comments

[ynakano]

コメントありがとうございます。
用語としては「互換性」より「可搬性」が適切ですね。
環境固有というのは確かにおっしゃる通りだと思うのですが、数が多くなってくると管理の問題が生じるので、できるだけ数を少なくしたいと考えてはいます。
(多様なデバイスで同じような処理をしているという事情があるので)

また有償製品のinitスクリプトを見ていると、1本のスクリプトで複数のOSに対応させようとしているケースがままあったりするので、なるべく可搬性を保つのが良いことだと思っていた部分もあります。
とは言え全てを予見するのは確かに無理ですね。

Cシェルスクリプトにはバグがある(あった？)ので私個人としては選択の余地なしなのですが、findの-printオプションも動かないケースがあるんですね。
外部コマンドの扱いについては、私の場合スクリプト冒頭で全て変数化してフルパスを定義しています。これで多少なりと修正がしやすくなると考えています。

[ikedas]

変数でフルパス定義はわたしもやっています。ただこれは、パッケージ管理システムからの自由がある一方でPATHの設定値に信頼をおけない環境で必要な対応策でもあったのかなと、最近は思います。あまり関係ないですが。

[ynakano]

もう一つフルパス定義をする理由があるとすると、aliasの影響を避けたいというのがあります。
cronに仕掛けたスクリプトがrm=rm -iで引っ掛かっていた事があります。

Answer 2

フルスクラッチ。
基本専用アプリ連携なので互換性を考える必要がない。

システム要件ありきの開発でもあるため

Comments

[ynakano]

コメントありがとうございました。

Answer 3

当たり前のことになりますが、どこまで移植する可能性があるかと言うこと次第でしょう。
また、そのままで動かなくても、機械的な書き直しで済むのなら、レアな移植可能性まで最初から考慮する必要も無いかと。

機械的な書き直しで済まないものとなると、配列くらいでしょうか。

あと、FreeBSDのshだと、$((式))は書けるようです。私は数値計算代入はletを使いますが。

Comments

[ynakano]

コメントありがとうございます。
質問文で書いた私のケースがまさにレアケースで、ベンダがOS部分に手を入れたセキュリティデバイスへの移植でした。
数値計算ばかりか配列まで使っていたので、移植というよりゼロベースの作り直しになってしまったのが、ある意味トラウマになっているのかもしれないです。

作成したスクリプトの管理の問題もあるので、可能な限り一本化しておきたいと思うのですが、どこまで気にするかはそれこそ必要性次第ですね。
とりとめのない感じで申し訳ないです。

otnさんの他の回答を見ていて、数値計算にはletを使っているなぁとは認識していたのですが、メリット等があってのことでしょうか？
よろしければお聞かせいただけるとありがたいです。

[otn]

> メリット等があってのことでしょうか？
括弧が不要なので、見やすいというメリットがあると思います。

[ynakano]

なるほど。ありがとうございました。

[otn]

後は、スクリプトの種類でしょうかね。
汎用ツール的なスクリプトと、運用ジョブ的なスクリプトだと、前者は汎用を目指して構文だけじゃなくて使う外部コマンドにも注意して、後者は特定環境で動けばいいか。