その結果、3つのファイルがありました。
- 親クラス-わずかな変更を加えて、オンライン記事から取ったクラス
- クラスの設定-シグナルへの反応、コマンドへの反応、実行する静的設定のセット
- 起動スクリプト-デーモン自体の最初の2つを収集します
次に、3つすべてのロジックを説明します。
すべてがGithubにあることをすぐに言わなければなりません。 pythonを簡単に読むと、非常に不適切なテキストを読むのがはるかに難しくなる可能性があるためです。
実際、最初のファイルには、説明するものはまったくありません。これらは、 この記事から取られたほとんど変更されていない3つのクラスです。 そこの変更のうち、シグナルハンドラクラスがデーモン自体にアタッチされ、処理されたもののリストにシグナルを追加することだけが、悪魔化手順自体に組み込まれました。
2番目の部分はもう少し興味深いものになります。 次の3つのクラスがあります。
1）SigFunctionsCon-シグナルに対する反応が含まれています。 初期化時に、デーモンはメソッドにアクセスできるようにデーモンのインスタンスを受け取ります。 各メソッドは、名前を処理するシグナルに対応する必要があります。 たとえば、次のように：
def SIGTERM(self): sys.stderr.write("BB!\n") sys.exit(0)
内部メソッドとフィールドは何でもかまいません。
2）ReactFunctionCon-コンソールコマンドに対する反応が含まれています。 初期化時に、デーモンも受け取ります。 名前による各メソッドは、応答するコマンドに対応する必要があり、引数（コマンドラインで実際にコマンドの後に続くもの）を取ることができます。 例：
def stmess(self,message): print message self.__ourdaemon.start()
3）StatCon-あらゆる種類の静的デーモン設定が含まれています。 現時点では次のようになっています。
class StatCon: Help = "Autmation has be applied to distribution sistem feeder for a long time, aspecially as related to protection and the restoration of some parts of the feeder." def run(self): while(True): time.sleep(1) PidFile = "/tmp/daemon-naprimer.pid" Inputter = "/dev/null" Outputter = "/dev/null" Errorer = "/home/espresso/lid"
したがって-
引数が関数に誤って渡されたときに出力されるヘルプ文字列（おそらく、このメッセージを表示するデフォルトのヘルプコマンドを作成する必要がありますか？）
runメソッドは、実際にはそれが本来の目的であり、デーモンが行うことです。
pidファイルのアドレスは、プロセスなどを保存するためのものです。
入力、出力、エラー-ロギングなど。 デフォルトで/ dev / nullに送信されます
中央のスクリプトは、コードのみに関心があります。 一般的に、デーモンクラスを継承し、以前のファイルからすべての設定を収集し、デーモンによってそれらを分解し、コマンドを受け取ります。
さて、実際の質問：
何が悪いのか、そうでないのは何ですか？
どういうわけかGPLをこれに帰すべきだと思いますか、それとも傷つけてはいけないと思いますか？
以前の著者を適切に示しましたか？
事前に感謝します。
参照：
Github
初期スクリプト