主な違いは、プログラムにはプログラムの「内容」に拘束されない広大なシェルがあることです。 プラットフォームに応じて、これらはマニュアルページ、複数の言語のサポート、インストール/アンインストール機能の存在、インターフェイスアグリーメント（コマンドライン、または他の相互作用の手段）の実行、一般的なレジストリのインターフェイスなどになります...文書化された環境では、さまざまな状況に対応します（これで最も良いのは、。/ configureを使用して、実際にどこにあるのか、この（通常の）プラットフォームでは何が可能で何ができないのかを判断するUNIXプログラムです）。
スクリプトはまったく逆の意味で、特定の問題を「今ここで」解決するように設計されています。 solaris、freeBSD、cygwinを搭載したwindows組み込み標準で、統計を送信するスクリプトが同時にこれを行うことができるとは誰も期待していません。
数学的およびプログラミングの概念によれば、管理スクリプトとプログラムに違いはありません。 彼らは同じ原則に基づいて動作し、一般的に言えば、ほとんど同じことを行います。
スクリプトとプログラムの違いは管理上の問題です。
ほとんどすべてのプログラムには、3つの重要なコンポーネントがあります。
- 自明でないアルゴリズム。
- 技術サポート、実績のあるベストプラクティス、典型的な実装スキーム、既製の構成。
- 許可された（文書化された）構成での作業環境への適切な統合。
これらのコンポーネントについて詳しく見てみましょう...
1）アルゴリズム。 プログラムには、まず特定のアイデアがあり（実際にはプログラムを実行します）、次にバインディングがあります。 構成の読み取り、syslogへの出力、メールによる通知、およびメインタスクに関係のないさらに千の操作。 しかし、プログラムは設定の読み取りやログへの書き込みではなく、その目的のために使用されます。 したがって、通常、アイデアは、何らかのアルゴリズムで何らかのアクションを実行することです。 自明でないアイデア。 実際のコードでは、これはxml-configを読み取るよりも少ないかもしれませんが、同時に、作業アルゴリズムはプログラムの本質です。 「データ処理」（SQLなど）、数学（md5sumなど）、または特定の鉄片の特定の機能（ファイル形式）のいずれかを使用できますが、作業の原則を適切に理解するには、対象分野で常に高い資格が必要です。 すべてのプログラマーがOpenSSLコードを読み取ることができることは明らかです。 優秀な数学者だけがOpenSSLアルゴリズムを理解できることは明らかです。
しかし、私たちはプログラムについて、スクリプトについては書いていません。 そのため、スクリプトは自明でないアルゴリズムを実装しないでください。 スクリプトにbase64の類似物を書く場合、これは悪いスクリプトです。 「open socket、write」メソッドを使用して、スクリプトでsmtp経由で送信するメッセージを作成する場合、これは嫌なスクリプトです。 スクリプトでcomポートからデータをキャッチし、そこに（UPSを制御するために）答えを書く場合-これはスクリプトではなく、何らかの種類のスクライブです。
スクリプトには、「サブジェクトエリア」の観点からアルゴリズムを含めるべきではありません。 スクリプトにはサブジェクト領域がありません。スクリプトは、サブジェクト領域ですでに動作しているプログラムのバインディングです。 場合によっては、スクリプト言語はすべてのツールを提供できます。
if md5.md5sum（open。（$ check）.read（））！= url.openurl（$ control）.read（）：
smtp.sendmail（$ from、$ to、「データチェックに失敗しました」、「$チェックのmd5sumが$ contフォームのコントロールサムと一致しません。」）。
これはスクリプトです。 ただのスクリプト。 彼は驚くほど多くの仕事をこなしているという事実にもかかわらず。 しかし、md5（md5（またはurl、open、またはsmtpなど）の実装を含む5行上のスクリプトで宣言されたクラス）がある場合、これはすでにプログラムへの試みです。 しかし、プログラムはそれを構成するアルゴリズムよりもはるかに複雑であり、スクリプトなどに実装すべきではありません。 絶対に。
2）プログラムには既知の動作が必要です。 数学者は、プログラムの動作を包括的な用語で説明することを提案します。 練習では、通常、アルゴリズムに加えて、プログラムにはその動作に影響するバグと機能が含まれているため、それらに適応する必要があると言われています。 プログラムを使用するいくつかの練習がある場合、それらに適応することははるかに簡単です。
「KDCはかつて有効でしたが、今は無効です」-このメッセージがスクリプトからのものである場合-すべて、埋めます。 その場で。 このプログラムには非常に合理的なメッセージがあり、グーグルで何が間違っているのかを見つけることができます。 これは、プログラム内に特定の客観的なロジックが存在することの直接的な結果であり、具体的には、ユーザーがそれを学習するのではなく、行動的に受け入れることを要求します。 つまり、プログラムの動作に関する一連のステートメントとして。 「このバージョンのプログラムは、サイズが2GBを超えるファイルを認識しません。」 これはアルゴリズムに適合しません（適合している場合は、離散数学のその方法を占有します）-しかし、実用的な意味でこれを知る必要があります。 「このプログラムは、アップロード/ダウンロードの対称的な負荷の条件下でひどく動作します。2つのコピーを実行することをお勧めします。それぞれのコピーは独自の方向で対称的に動作します」 アルゴリズムが複雑になるほど、その研究、適応、および詳細な研究により多くの時間を費やす必要があります。 すべてに十分な生活がありません。つまり、与えられたとおりに受け入れて、重要なことに集中するのは簡単です。
それどころか、スクリプトは、スクリプト言語の知識を修正して、それを見るすべての人にとって非常に明確でなければなりません。 なし
(if every in self.__datarange__ is not in any map(__systable__.lang, __localtable__.map, lambda (a,b):[a in b or b in a for every __sys__.pair(a,b)])) raise "Missed i18n constitution".
3）スクリプトは、今ここで問題を解決します。 プログラムは、問題を解決します_TAM_I_ ALWAYS_（第2節の操作経験に合わせて調整）。 スクリプトを作成すると、システムで動作するようになります。 他のシステムでの無料使用には適していません（ただし、簡単に適用できます（ポイント1を参照）。） プログラムは多数のアプリケーションに適応できる必要があります。この適応をスクリプトに実装すると、その単純性が失われ、実際にはプログラムに変換されます。 さらに（alas、ah）ですが、プログラムの正しい書き方を知っていることは、正しいアルゴリズムを書くことと同等ではありません。 素晴らしいライブラリを作成できますが、週の最初の日が月曜日（または幸運な人として2日目）のマシンで実行できない場合、ライブラリは価値がありません。 それについて考える必要性はすでにプログラムを書いていることです-これはスクリプトには受け入れられます（望ましくありませんが）。
さて、スクリプトとプログラムのもう1つの重要な違いです。 プログラム（ライブラリの形式）は互いに「オーバーラップ」できます。 このプログラムには、libZZZとlibAAAを使用するlibYYYが必要ですが、libAAAはlibZZZとlibcを使用します。 これは正常です。
スクリプトは他から依存しないでください。 スクリプトが3番目に依存する別のスクリプトのサービスに依存する状況は異常です。
中毒について話していることに注意してください。 他のスクリプトを呼び出して一般化された結果を生成するスクリプトを想像することはかなり可能ですが、これはすでにエッジです。 もう少し複雑です（たとえば、「スクリプトBが機能しなかった場合、スクリプトAを実行する」）-既にファウルの限界を超えています。 良くない また、スクリプトAが機能しなかったが、報告しなかった場合はどうなりますか？ または、少し動作しましたが、スクリプトBが完了できないように落ちました（そして、スクリプトAの作成者として、私たちはそのようなことを考えることができませんでした）？
それでは、良いスクリプトは何をすべきでしょうか？ いくつかのプログラムを特定のシステムにマージします。 プログラムをコンストラクターの詳細と見なすことができます。 そして、コンストラクター自身-スクリプト用。 スピンドルのねじ山を切らないでください-ねじ山のあるスピンドルを取ります。 このガムから楕円ローラーを作成しないでください-それはまだうまくいきません。 端に穴のある正方形のプレートがない場合、これは詳細の欠如の問題です。 長方形のペアから正方形のプレートを作成しようとすることができますが、何百もの長いストリップを作成しないでください。
スクリプトがプログラムに退化することがあります。 突然、特定のロジック（アルゴリズム）がスクリプトに表示されますが、これは重要な（かつ有用な）ものになります。 この時点で、これをキャッチする必要があります。3倍の時間を費やすのが面倒ではなく、プログラムにする必要があります。 プログラムとスクリプトを区別する「肉」を提供します。 100個の条件チェックを追加し、すべての定数を構成可能な変数に置き換え、「異常な」条件での作業に備えます。 公開することをお勧めします（その後、使用方法を習得できます）。
通常のパイプは、単純なプログラムを構築するためのほぼ完璧なツールです。
lssomething | grep "bla-bla" | sendmail root@host.ru -s "bla-bal for something"。
スクリプトが終了する行を見つけるのは困難です。 サイクルはまだ耐えられるとしましょう。 状態の確認は正常です。 しかし、ループ内の状態をチェックする（ループを終了する以上のこと）は、すでに悪いことです。 条件を確認するためにサイクルが開始されるサイクルがある場合、これは100％プログラムです。 プログラムに必要なものがすべて揃っていない場合、これは単に非常に悪いプログラムです。 しかし、スクリプトではありません。
「有用なスクリプト」のコレクション（ ここ （forum.sysadmins.ru）など）を見ると、これらがプログラムであることを理解しています。 サポート文書、インストール手順、条件の確認なしの恐ろしいプログラム...不可能です。
このようなスクリプトの使用は、極端なkutsesti作業環境の兆候です。 ある時、私は彼らと仲良くしようとしましたが、これは間違いであるという結論に達しました。 同様のスクリプトのセットよりもツールキットのセット（つまり、特定のものを完全かつ適切に実装する本格的なプログラム）を持っている方がはるかに正しいです（もう一度繰り返します-プログラムは同じスクリプト言語で記述できます-スクリプトとプログラムの違いは非プログラムバインディングです：ドキュメント幅広いシステムでの生活への適応性）。
コピーペーストされたスクリプトの使用は、フロッピーディスク上の便利なプログラムマイニングの初期のdosコピーのようなものです。 それは機能します-私たちは喜んで、機能しません-気にしないで、すべてが壊れています-私たちは怒っています。 コピーペーストされたスクリプトとプログラム（および最小限のバインディング）を選択する条件では、プログラムを選択する必要があります。 プログラムの実施には、研究、設立などの追加の努力が必要であっても プログラムを確立すると、プログラムを受け取ります。 スクリプトをデバッグすると、松葉杖だけが得られます。その強度と耐久性は、作成者でさえもわかりません。
同様の状況が発生するたびに、スクリプトを作成するか、プログラムを検索するには、プログラムを検索することから始める必要があります。 プログラミングは楽しいので（はい、nagios、監視スクリプトを自分で書く）、他の人の学習は退屈です（地獄のように機能しませんか？）。 しかし、「プログラミング不足」の結果は、作成した「煙突」のドキュメントが不足していることです。 そして、実装されたソリューションの結果は、単独で動作できるシステムです。