bashスクリプト/usr/bin/local/myscriptがあります。私は通常、外部ソフトウェア（私の場合はAutohotkey）でファイルを実行します。デフォルトでは、スクリプトはすぐに完了してウィンドウが閉じられるため、ウィンドウにログ、情報ログ、またはエラーログが表示されないことを意味します。 。だから私は、プログラムが正常に動作しない場合にデバッグできるように、全体の実行ステップを「作成」するのが好きです。しかし、単にscript ~/script.txtファイルの最初の行に入れるmyscriptだけでは機能しません。何が起こっているのかわかりません。ファイルの次の行はデフォルトでは実行されません。もしそうなら、bashファイルで「スクリプト」を使用する（正しい）方法はありますか、それとも「スクリプト」に良い選択肢がありますか？
ベストアンサー1
しかし、単に
script ~/script.txtファイルの最初の行に入れるmyscriptだけでは機能しません。何が起こっているのかわかりません。ファイルの次の行はデフォルトでは実行されません。
シェル解析の場合は、myscript外部script ~/script.txt実行可能ファイルを実行するコマンドです。実行ファイルscriptの場合も同様です。
実行可能ファイルがまたはある場合は、実行可能ファイルsleepをtar解釈lsする前に実行可能ファイルが完了するまでシェルが待機することを期待できますmyscript。つまりscript、シェルはscript完了するまで待ちます。
script対話型使用のためのものです。script ~/script.txt解釈されたシェルではなく対話型シェルを実行しますmyscript。 「ウィンドウが閉じています」（そうでない場合）と書かれているため、ウィンドウを表示する一部の端末エミュレータで実行されているとscriptします。myscriptそうであれば、（を使用してscript）この内部シェルがによって開始されるのを見ることができ、シェルscriptが待っている間にそれと対話することができます。script内部シェルで何をしているかを文書化します。内部シェルを終了すると終了し、scriptシェル（たとえばmyscript）が続行されます。ただし、ターミナルエミュレータを閉じたときにシェルがSIGHUPを受け取り、続行していない可能性があります。
scriptシェルが引き続き実行されても、内部で呼び出すことがmyscriptデバッグに役立たないことは今や明らかになったので、これは実際には重要ではありません。myscript
デバッグには少なくとも2つの方法がありますmyscript。
スクリプトの stderr をログファイルにリダイレクトします。これはスクリプトで実行できます。
# just after shebang exec 2>/path/to/logfile出力が標準出力から生成される場合
myscript（重要で実際にどこか（パイプやリダイレクトを介して）に移動する場合）、出力を中断したくありません。ただし、通常は端末に印刷され、それを記録したい場合は、stderrとstdoutをログファイルにリダイレクトします。# just after shebang exec 2>/path/to/logfile 1>&2myscriptこの方法は、端末なしで実行しても機能します。または、スクリプトが
bash最後に対話型シェルを実行するようにします（例：）。新しいシェルはウィンドウが閉じることを防ぎ、これまでスクリプトが端末に印刷した内容を見ることができます。明らかに端末が必要です。それ自体または他の実行可能ファイルmyscriptで発生した場合。これを考えてください。exitkillexecbash何らかの理由でスクリプトから開始された対話によって端末などが
bash消去された場合は、代わりにそれを使用してくださいsleep 3600。要点は、実際に追加のシェルを必要とせずに前の出力を確認できるように、ターミナルエミュレータを十分に長時間開いたままにするプロセスが必要であることです。
どんな方法を選んでも
set -x
シェルがこれを早期に解釈しmyscript、実行時にコマンドと引数を印刷するようにします。これにより、有用な洞察を得ることができます。