私は2011年のシェルスクリプトを持っています。その目的は、さまざまなUNIXシステムで実行することです。シェルスクリプト - エコーの代わりにbin/echoを使用する理由？
スクリプトは特定の変数を定義しており、その背後にあるロジックを理解していないため、なぜこのように行われているのか知りたいと思います。例えば：
代わりスクリプトに直接echo又はgrepを使用する、これらの変数は次のように定義される：Solarisまたは他のための
ECHO="/bin/echo"
GREP="/bin/grep"を（Linux用）
は、対応するパスが同様に定義されます。 これらは、次に使用されます${ECHO} "something out"
この練習の目的は何ですか？それを直接使用できないのはなぜですか？
他の人が指摘したように：代わりに、スクリプトの先頭にFIND変数を設定する必要に応じて、1には、名前を変更、代替が存在しない場合は、標準findコマンドを使用しての既定の動作に通って落ちる、ラッパーを指定することができますアウト、それはそれらの行は、彼らがあるべきより多くの可能性が正しいことはほとんどありません：
ECHO="/bin/echo"
GREP="/bin/grep" # (for linux)
echo：ksh（お好みのシェルにするために使用Kornシェル、）、csh（Cシェル、太陽のデフォルトのシェル）とsh（Bourneシェル、それはPOSIXだった前に）すべてが自分内蔵していたバージョン（ほとんどが-n引数の周り）であったechoのものです。したがって、スタンドアローンのプログラム/bin/echoが移植性のために使用されることがありました。そのために支払うべきパフォーマンス価格があります。
grepなど：外部プログラムの絶対パス名をスクリプトに設定することをお勧めします。主な理由はセキュリティです。理論的には、ユーザーは自分のバージョンをローカルディレクトリに用意して、PATH変数を変更することができます。 PATH、および他のすべての環境変数は、多くの場合、依然としてセキュリティリスクとみなされます。 2番目の理由は、ディレクトリの検索のパフォーマンスオーバーヘッドが$PATHであることです。これは、追跡されたエイリアス（ksh）またはハッシュ（bash）の日以前です。
私はこれらの意見をすべて購読していないことを繰り返しますが、私は何人かの人と議論しましたが、それは説明です。私の意見では、このプラクティスは解決するよりも多くの問題を引き起こします。
編集：私が言及しているプラクティスは、1970年代と80年代にさかのぼります。なぜ彼らは2011年からのスクリプトになるのだろうか？おそらく「私たちは常にそれをしている」、つまり「会社の方針」、つまり誰も知っていない、または気にしていないからです。あるいは、古いウェブサイトや本、あるいはこれが良いアイデアだと信じている人からさえ、コピーアンドペーストのケースかもしれません。
私は '/ bin/echo'を使うのが今日のように意味がある問題で走りました。組み込みの 'echo'は、シェルのバージョンに応じて埋め込まれたバックスラッシュのエスケープを扱うようです。私がPOSIXの '-E'スイッチを使用することがわかった唯一の信頼できる方法は、バイナリバージョンを使うことです。 –
何でもこの例ではです。
（バイナリの場所が異なるシステムに移動するときに変更が必要になるため）スクリプトの移植性が低下し、パフォーマンスが低下します（PATHルックアップがキャッシュされている場合はシェル組み込み関数の使用を抑えるため）ルックアップコストを節約してパフォーマンスを向上させます。
1つの警告：一部のシステムでは、/bin/は、POSIXツールの標準的な場所ではありません。たとえば、/usr/xpg/bin/shはPOSIX shの場所になり、/usr/xpg/bin/awkは古代のSunOSシステムのPOSIX awkの場所になります。
このようなシステムでPOSIX準拠ツールを使用するには、スクリプトの先頭に定義されている変数にこれらのパスをハードコードするのが間違っています。
このようなシステムでPOSIX準拠ツールを使用する正しい方法は、/usr/xpg/binを/binの前に置くPATHを指定するだけです。例えば、スクリプトは[ -d /usr/xpg/bin ] && PATH=/usr/xpg/bin:$PATHを指定することができ、したがってこの目的に役立ちます。
また、GNU findを使用したいとします。
# use GNU find if under a name other than "find"
if type gnufind >/dev/null 2>&1; then
find() { gnufind "[email protected]"; }
elif type gfind >/dev/null 2>&1; then
find() { gfind "[email protected]"; }
fi
あなたがどこか妥当で官能的であると感じるシェルのランダムなチャンクを信頼することは、良い習慣ではありません。あなたが他の人のスクリプトに見られるランダムなものをコピーすると、あなた自身に参加するかもしれません。 –
ところで、これは 'bin \ echo'ではなく'/bin/echo'でしょう。 –
@ JimLewis、それはスクリプトの目的であり、実際の目的ではありません。むしろ、私はむしろ強調して、移植性ではなく、問題の練習が損害であると強調している。 –