いくつか感じたことを書きます。一部は本などの受け売りも入っているかもしれません。
自信がなければ #!/bin/sh とは書かず #!/bin/bash のように明示的に指定する
シェバンの #!/bin/sh は環境によって大きく異なるものを指します。
もしこの記述を「今」するのであれば、POSIX shellの挙動に合わせるという意思があるときだけにしたほうが良いと思います。
この説明でまゆをひそめる人であれば、逆に#!/bin/bash の1行を読んだ時にその意図を外すことはないはずです。
自信がなければ、記述時点で使った実行環境が分かるようにする
あくまで人向けのメモというレベルであって、#!/bin/bashのように実行環境を縛る目的では使えません。しかし、コードの利用者やあなたの記事の読者、とくにShellの扱いに秀でている人には良いヒントになると思います。
Bashですら、バージョン3と4で挙動が違います。連想配列を使っているコードで #!/bin/bash と書かれていても、Bash 3系では利用できません。
ではBash 3などという古いものを使ってるUnix系環境がこれを読んでいる大半の読者の近くにあるのか、と言いますと、あります。OS X 10.10.2 です。
$ /bin/bash --version
GNU bash, version 3.2.57(1)-release (x86_64-apple-darwin14)
Copyright (C) 2007 Free Software Foundation, Inc.
#もともとこの記事のきっかけになったのは、納品環境がLinuxな中、Mac内に仮想サーバ環境を含む実験環境を整えたいと思ったからでした。
実行時にバージョンを見るコードを書くのもよいでしょうが、もし書き手に能力がなければ中途半端に終わるのが常だと思われます。また、スクリプト実行者の個人的な環境(Macならbrewの使い方とPATHの通し方)に大きく結果が左右されます。
readlinkの-fオプションは、BSD系(Mac含む)には今のところないのです。
Windows使いがLinux前提の記事を読んだ時(あるいはその逆)と同じという面はありますね。
Shellという言葉にまず注意する
人によって色々な含意がある言葉です。広く認知されている単語であるのに、定義が曖昧なまま多くの人が色々な期待を詰め込もうとする場合、注意が必要です。
最新ツールの最新オプションを使って高度なことをすることも指しますし、BSDやAIXでも動くといった互換性の重要性からPOSIX shellの仕様を始めとする保守的なスクリプトを良しとする (kshでもzshでも動く!) 人も同じ言葉で語ることがあります。