$ HOME/binディレクトリに、手作業でロールした実行可能なスクリプトがたくさんあります。一部はbashで記述され、一部はRubyで記述されています。それらのすべては、シェルに使用するインタープリター(私の場合はbashまたはRuby)を指示するShebang行があります。
これらのスクリプトにファイル拡張子を付けて、どのスクリプト言語で記述されているかを示す方がよいのでしょうか。たとえば、Ruby内のスクリプトには* .rbサフィックスがあり、bashスクリプトには* .shサフィックスがあります。
現在、これらのスクリプトはファイル拡張子のない単純な名前を持っています。
ベストプラクティスは何ですか?
将来スクリプトを整理したい場合は、ls *.rb
やcp *.sh
などのワイルドカードコマンドを実行できます。
私の意見では、早期に開始するか、後で後悔します。
vim
のようなエディターは、 Shebang またはファイル拡張子に基づいて、正しい構文の強調表示を適用することもできます。
これは、さまざまなエディターでモードラインを使用して行うこともできます。例えば。 vimの場合:
# vim: ft=sh
まあ-人生のほとんどのものとして:それはあなたのニーズに依存します。
これらのスクリプトはbinディレクトリにあるとおっしゃっていましたが、これらのスクリプトはコマンドラインから呼び出す必要があると思います。 serとして、bla.kshまたはfoo.bashと入力しなければならない場合、それは迷惑であると考えます。また、coderが別のインタープリターに移動することを決定した場合、コマンド名も変更され、これらのツールを使用する他のスクリプトを修正する必要があります-ser =とcoderはまったく同じ人物です。
しかし一方で、プロジェクトビルドディレクトリでは.shや.tclなどの拡張子を使用しています。このようにしてmake機能を使用してファイルを宛先ディレクトリに展開できますが、この段階でファイルサフィックスを削除します。
明らかに、bin
ディレクトリ内の実行可能ファイルと編集可能な「ソース」ファイルの間にはいくつかの違いがあります。
#!
行のスキャンに失敗するインテリジェントでないツールを支援することが役立ちます。.pm
、.sh
、または.so
を含めるのが一般的です。コンパイルされたプログラムの場合、「ソース」と「実行可能」の違いは明白です。1つはソースコードを含み、もう1つは機械語または解釈済みバイトコードを含みます。スクリプトの場合、明確な違いはありませんが、make
コマンドは、「スクリプトのソースコード」と「スクリプトの実行可能バージョン」の間の概念的な分離を維持します。 「シェルスクリプト」は単にcp
です。
別の$HOME/source
ディレクトリを保持することをお勧めします。
ln -s ../source/foo.sh $HOME/bin/foo
によって作成されたようなシンボリックリンクを維持する。またはinstall -m 755 foo.sh ../bin/foo
を使用して、変更(およびテスト)後に手動でコピーします。または$HOME/source
から$HOME/bin
にコピーする前に、Makefile
ルールを使用して構文チェックを実行する脚注:シェルスクリプトモジュールは別のシェルスクリプトでのみ使用でき、.
またはsource
組み込みコマンドを使用してそのスクリプトの内部コンテキストを変更します。これは、(他のプログラムと同様に)別のプロセスとして実行され、その親プロセスを変更できない実行可能スクリプトとは異なります。おおまかな規則として、モジュールは/usr/lib/name_of_program/name_of_module.sh
に入り、コマンドは/usr/bin/name_of_command
(サフィックスなし)に入ります。
それは必要はありません。カーネルは、使用する正しいインタープリターについて(#!
行によって)既に通知されており、すべての一般的なテキストエディターもそれを読み取るため、拡張機能を追加しても、タイピングを増やすだけで何の役にも立ちません。実行可能プログラムに拡張子があるのは、それが何らかの理由で(プログラムまたはユーザー、あるいはその両方にとって)重要な場合だけです。
一方、モジュールとライブラリは、ほとんど常に拡張機能を備えています(.rb
はRubyモジュール、.so
はELF共有ライブラリなど)。