どちらが良いですか？
#!/usr/bin/env sh#!/bin/sh- 空/タイトルなし
私は最初のものが最高だと思いましたが、Androidなどの一部のLinuxベースのシステムではパス名が欠落しているので、「移植可能な」シェルスクリプトを持つ唯一の方法はヘッダーを含まないと思います。
答え1
移植性の観点から、#!/bin/sh標準のUnixまたはLinuxシステムでほとんどPOSIX互換シェルを見つけることができると安全に想定できますが、それはすべてです。
FreeBSD、OpenBSD、およびNetBSD（DragonFly、PC-BSD、および他の派生製品など）にはbashが存在するため/usr/local/bin/bash（インストールされている場合）、この/usr/bin/env方法はLinuxとBSDの間の移植性を提供します。
Androidは標準のUnixまたはLinuxシステムではありません。ルート化されていない私のAndroid携帯電話にはシステムシェルが/usr/bin/envなくて/bin/bashも存在しません。/bin/sh/system/bin/sh
欠落しているシェルスクリプト#!（shebang）は、一部のシステムでそれを呼び出したシェルで実行しようとしたり、/bin/bash他のシステム（たとえば）で別のデフォルトインタプリタを使用したりする可能性があります。そして同時にこれAndroidでは動作できますが、他のオペレーティングシステムでは動作が保証されていないため、ユーザーはそうでない場合を選択できますbash。 （私はデフォルトのシェルであるFreeBSDでtcshを使用し、Shabanを持たないスクリプトは呼び出しシェルで解釈されます。）
私が座った場所から見ると、このような感じです。不可能Androidはモノを扱うため、AndroidとAndroid以外のシステム（LinuxまたはUnix）の間に移植可能なシェルスクリプトを作成します。
答え2
私の経験で#!/bin/shは、私はいつも#!/bin/bash私が開発したいくつかのシステムで正しい環境を見つけます。まだ例外が発生していません。私はまた、シェルスクリプト関連のテキストでよく使われることがわかりました。
同じことを言うことはできません#!/usr/bin/env。一部のシステムではこれをインストールしましたが、#!/bin/env過去にPythonスクリプトが破損していました。だから私は2番目の箇条書きを選択します。
上記の声明のいくつかのサポートは次のとおりです。
CentOS 5.7 バージョンでは、次のメッセージが表示されます。
$ which env
/bin/env
Ubuntu 12.04 Precision Pangolin:
$ which env
/usr/bin/env
また、少なくとも1つの古いシステムには、何らかの理由で管理者がインストールされていたことを覚えていますcoreutils（/optおそらくベストプラクティスではありません）。envそれがその一部であるためcoreutils、ユーザーは最終的にそれを取得します/opt/coreutils/bin/env。もちろん、すべてのシステムを使ったわけではないので、答えは限られた経験に基づいています。