私の基本的なUnix / Linuxスクリプト技術と不器用な英語を許してください。
Linux VMでスクリプトをテストしているので、work.sh
VMにsshを接続する必要があります。
ssh [email protected]
自分のアクセス権がある場合は、自分のホームフォルダからスクリプトを実行する必要があります。
[[email protected] ~]. work.sh param1 param2
バッチスクリプトで問題が発生するとエラーが表示されますが、VM / sshセッションでも追い出されます。
Connection to [email protected] closed.
だからもう一度ログインする必要があります。
nohupを試しましたが、エラー/ログもコンソールに出力したいと思います。この状況を処理するより良い方法は何ですか
答え1
set -e
台本にそのような内容があるようですね。この設定が有効な状態でソーススクリプト(を使用して実行. scriptname
)でエラーが発生した場合は、シェルを閉じることが予想される動作です。
スクリプトについての知識がなければ、スクリプトを実行しないと確信できませんが、タスクを.
実行する珍しい方法です。
実行してみましょう。
./work.sh param1 param2
スクリプトの実行を妨げる不足している実行ビットを克服したい場合は、次のことを試すことができます。
$SHELL ./work.sh param1 param2
あるいは、追加のシェルを起動して今のように実行することもできます。これにより、エラーメッセージが表示されることがあります。
$SHELL
. work.sh param1 param2
答え2
自分のアクセス権がある場合は、自分のホームフォルダからスクリプトを実行する必要があります。
[[email protected] ~]. work.sh param1 param2
スクリプトを呼び出す方法には、「一般呼び出し」と「ポイント呼び出し」または「購入」の2つの方法があります。
$ /path/to/executable
$ . /path/to/executable
違いは次のとおりです。最初のバリエーションは、オペレーティングシステムが新しいプロセス(シェルの子プロセス)を起動し、その中にあるスクリプトをロードして実行し、ロードされたスクリプトが実行を終了するとプロセスを再び閉じます。あなたが戻ってきました。シェルプロセスはおそらく別のプロンプトを表示します。
2番目のバリエーションは同様に動作しますが、1つの重要な違いがあります。つまり、子プロセスは生成されませんが、スクリプトは現在のプロセス。何が起こっているのかよくわかりませんがwork.sh
(コメントしたい場合は内容を投稿する必要があります)、どういうわけかログインシェルを抜けて接続が切断される可能性があります。前のポイントから始めないでください。これにより、再接続が切断される現象が発生しない可能性が高くなります。
ボーナス情報
私の経験によれば、初心者はいくつかの実験で何かがどのように機能するかを確認できるときに最もよく、最も速く学習します。だからここにあります:
次のスクリプトを作成して「my_script.sh」として保存すると、ドット実行と通常実行の違いを確認できます。
#!/bin/bash
my_x="abc"
my_y="def"
chmod 754 my_script.sh
実行可能にし()一般的な方法でスクリプトを実行し、定義された2つの変数の内容を表示することを忘れないでください。
$ ./my_script.sh
$ echo $my_x $my_y
表示される効果は次のとおりです。なし - 変数が設定されていません。理由は簡単です。スクリプトの開始時に別のプロセスが開始され、変数定義が発生します。そこプロセスが終了すると再び消えます。それ環境はあなたではありません。
これで、ドット実行を使用して同じスクリプトを実行します。
$ . ./my_script.sh
$ echo $my_x $my_y
abc def
今回は変数が実際に設定されていることがわかります。その理由は、スクリプトが一部の新しいプロセスでは実行されず、ユーザープロセスで実行されるためです。したがって、変数定義はユーザー環境で発生し、その後もそのまま残ります。