＃！/ bin / bashと＃！/ bin / shを使用する必要がある場合

ときである#!/bin/bashよりも、より適切な#!/bin/shシェルスクリプトでは？

要するに：

• POSIX sh仕様のスーパーセットを実装するシェルがいくつかあります。異なるシステムで/bin/shは、ash、bash、dash、ksh、zsh、＆cへのリンクがあります。（ただし、常にshと互換性があります。cshやfishは使用しないでください。）

• sh機能のみに固執している限り、使用でき（おそらくそうすべきです）#!/bin/sh、どのシェルであってもスクリプトは正常に動作します。

• bash固有の機能（配列など）の使用を開始する場合は、bashを具体的に要求する必要/bin/shがあります。すでにシステムでbashを起動している場合でも、他の人のシステムでは実行されず、スクリプトはそこで実行されないためです。（もちろん、zshとkshにも同じことが当てはまります。）shellcheckを使用して、バシズムを識別することができます。

• スクリプトが個人使用のみの場合でも、一部のOS /bin/shはアップグレード中に変更されることに気付くかもしれません。たとえば、Debianでは以前bashでしたが、後に非常に最小限のダッシュに置き換えられました。バシズムを使用したが、#!/bin/sh突然壊れたスクリプト。

しかしながら：

• でも#!/bin/bash非常に正しくありません。異なるシステムでは、bashは/usr/binまたは/usr/pkg/binまたはに存在し/usr/local/binます。

• より信頼性の高いオプションは#!/usr/bin/env bash、$ PATHを使用します。（envツール自体も厳密には保証されていませんが、/usr/bin/envそれでもシステムよりも多くのシステムで/bin/bash動作します。）

スクリプトの開発とデバッグに実際に使用したシェルに対応するシェバンを使用します。つまり、ログインシェルがbashであり、端末でスクリプトを実行可能ファイルとして実行する場合は、を使用します#!/bin/bash。配列（またはbash認識している機能）を使用していないため、好きなシェルを選択しても安全だと思い込まないでください。シェル（echo、関数、ループ、名前を付ける）には多くの微妙な違いがありますが、適切なテストなしでは発見できません。

これを考慮してください：あなたが離れて#!/bin/bash、あなたのユーザーがそれを持っていない場合、彼らは次のような明確なエラーメッセージが表示されます

Error: /bin/bash not found

ほとんどのユーザーは、適切なパッケージをインストールすることにより、1分以内にこれを修正できます。一方、シバンをに置き換えて、へのシンボリックリンクがある#!/bin/shシステムでテストすると、持っていないユーザーが問題を抱えることになります。ほとんどの場合、次のような不可解なエラーメッセージが表示されます。/bin/sh/bin/bashbash

Error in script.sh line 123: error parsing token xyz

これを修正するには数時間かかる場合があり、どのシェルを使用すべきかについての手がかりはありません。

シバンで別のシェルを使用する理由は多くありません。1つの理由は、使用したシェルが普及していない場合です。もう1つはsh、一部のシステムでパフォーマンスを大幅に高速化することです。また、スクリプトがパフォーマンスのボトルネックになります。その場合は、ターゲットシェルでスクリプトを徹底的にテストし、シバンを変更します。

あなただけを使用する必要があります#! /bin/sh。

シェルスクリプトでbash（またはzsh、またはfish、...）拡張機能を使用しないでください。

シェル言語のすべての実装（シェル自体に付随するすべての「ユーティリティ」プログラムを含む）で動作するシェルスクリプトのみを記述してください。これらの日、あなたはすることができますおそらく取るPOSIX.1-2001（ないシェルとユーティリティがすることができ、何のために権威として-2008）をしていますが、（例えばSolarisのポートにするとレガシーシステムへのスクリプトを1日と呼ばれることもあることに注意してくださいまたはAIX）シェルおよびユーティリティが1992年頃に凍結された。

まじで？

はい、真剣に。

事はここにあります：シェルはひどいプログラミング言語です。唯一の目的/bin/shは、すべての Unixインストールで保証されている唯一のスクリプトインタープリターであることです。

ここでは、他のことだ：コアのPerl 5インタプリタのいくつかの反復は（/usr/bin/perl）である以上よりも、ランダムに選択されたUnixのインストールで利用可能である可能性が高い(/(usr|opt)(/(local|sfw|pkg)?)?/bin/bashです。他の優れたスクリプト言語（Python、Ruby、node.jsなど—シェルと比較する場合、そのカテゴリにPHPとTclを含めます）も、bashやその他の拡張シェルとほぼ同じくらい利用可能です。

したがって、bashスクリプトを作成するオプションがある場合は、代わりにひどくないプログラミング言語を使用するオプションがあります。

さて、単純なシェルスクリプト、つまりcronジョブなどからシーケンスでいくつかのプログラムを実行するだけの種類のスクリプトは、シェルスクリプトのままにしておくことで問題はありません。ただし、単純なシェルスクリプトには、配列や関数は必要ありません[[。また、他に選択肢がない場合にのみ、複雑なシェルスクリプトを記述する必要があります。たとえば、Autoconfスクリプトは適切なシェルスクリプトです。ただし、これらのスクリプトは、構成中のプログラムに関連するすべてのインカネーションで実行/bin/shする必要があります。つまり、拡張機能は使用できません。最近の古いプロプライエタリUnixを気にする必要はないでしょうが、おそらく現在インストールされていないオープンソースBSD を気にする必要があります。bashデフォルトでは、最小限のシェルとのみを提供する組み込み環境busybox。

結論として、ポータブルシェル言語では使用できない機能を望んでいることに気付いた瞬間、つまり、スクリプトが複雑すぎてシェルスクリプトを維持できないという兆候です。代わりに、より良い言語で書き直してください。

通常、機能よりも時間が重要な場合は、より高速なシェルを使用します。shは多くの場合、ダッシュにエイリアスされ、ルートのcronタスクまたは（ナノ）秒ごとにカウントされるバッチ操作に使用される傾向があります。

さらに簡単に言うとsh、ほとんどのシステムでの移植性が最も重要でありbash、bashのバージョンでサポートされている場合、アレイなどの特定の機能を使用したい場合に使用します。

• sh（ほとんどの場合）、特に必要な場合はbash（またはkshなど）

最も安全なパス。ハードコーディングされた場合、/ usr / bin /になりますshellOfChoiceが、私は常に現在使用しようとしている新しい規則です-変更PATHを介した「デフォルトの場所」が変更される可能性があるため：

＃！/ usr / bin / env shまたは
＃！/ usr / bin / env bash
またはperlスクリプトの場合
＃！/ usr / bin / env perl -w

もちろん、スクリプトが新しいPATHを決して自動的に取得しない理由がある場合は、それをハードコーディングし続けます-そして、/ usr / bin / somethingが使用する可能性が最も高いパスになります。