最初は「バッシュルーレット」をプレイしているようで、ちょっと面白かったですが、今では飽きてきました（笑）
ターミナルでゼロ以外のコードで終了するコマンドはターミナルウィンドウを閉じます
set -eおそらく、ターミナルソースのどこかに bash スクリプトを設定したのではないかと言われました。
確認しましたが、 .bash_profile/ .bashrc/は含まれて.profileいないようです。set -e
他に明らかな犯人はいるでしょうか?
答え1
そうですね、確かに、set -e私の問題を引き起こしたのは気まぐれな人でした。
set -e私が見つけた方法はbash -lx
最善の方法は、次のものを使用することです。
bash -lx > lx.log 2>&1
set次に、そのログ ファイルを開いて、 ...を検索します。
問題が見つかったらset -e、その行を削除すれば問題は解決するはずです。(ただし、マシンを再起動すると良いでしょう)。
私の場合、 はset -e.bash_profile がソースとするファイルにありましたが、 行は .bash_profile 自体にはありませんでした。
答え2
問題を解決したいだけならset +e、.bashrc終わり。
掘り出すこともできます。他にも が存在する可能性のある場所はたくさんありますset -eが、これですべて解決します。
ただし、set -eが の一部である場合、$PROMPT_COMMAND上記の方法は機能しません。 試してみてprintf '%s\n' "$PROMPT_COMMAND"、その内容を確認してください。
答え3
私の場合、 はset -eどの bash スタートアップにも存在せず、set +eに追加しても.bashrc問題は解決しませんでした。
結局、これはset -e私がプロジェクトで頻繁に実行するbashスクリプトの中にあり、そのスクリプトを. ./my-dev-script.sh次のように実行していたのです。私のbashエイリアスを尊重する。
私が気付いていなかったのは、その追加情報を.先頭に付けて実行すると、スクリプト内の bash オプションが通常のターミナル セッションすべてに引き継がれるということでした。
個人の bash エイリアスを尊重する bash スクリプトを実行するための新しいソリューションが必要ですが、少なくとも不正の原因は見つかりましたset -e。 を通常どおりに実行すると、./my-dev-script.shイライラする「Bash ルーレット」シナリオを回避できます。