在 Kubuntu 20.04 或 KNOPPIX 9.1 中，在 Konsole 下的 KDE 中，許多視窗以及每個 bash 版本 5.2.15(1)-release (i686-pc-linux-gnu)。
這個問題描述的問題是我在過去幾週經常出現的（但以前從未出現過）。
它總是由來源腳本中的錯誤命令列或在 shell 提示字元後鍵入的命令列引起的。
有時（不是今天）bash 會無止盡地衍生新流程。
今天我可以報告錯誤的命令行，這就是原因——它不是我輸入的字面意思，而是 ps 顯示的內容：
ps -Flwwc -t pts/14
ps 在「CMD」欄中顯示：
sed -r eval s=(.*)=\1; ZZZZZZZZZ;=p /root/.bash_history
請注意，這個錯誤命令不是我的問題（我知道我正在嘗試什麼以及下一步是什麼）。
問題是，瘋狂的狂歡做了什麼以及有什麼幫助。
bash 無限連續地顯示這兩行：
sh -c: line 1: syntax error near unexpected token `('
sh -c: line 1: `val s=(.*)=1; ZZZZZZZZZ;=p'
在另一個終端的 bash 中我運行
ps -Flwwc --sort=start_time -t pts/14
我看到有兩個子進程處於活動狀態：
sed（如上圖）less
兩者的 PPID 都是損壞的 bash。
在破碎的打擊中沒有任何手段。例如
打字Return帶來的內容較少。關閉 less，我處於 bash 提示字元中，好像一切都會好起來。在另一個終端中，ps -Flwwc ...一切似乎都正常了：兩個子進程消失了，底部的進程是損壞的 bash。
現在回到損壞的 bash：如果我輸入Return或輸入Ctrl- C，我會得到這兩行的無限序列，並在另一個終端中ps -Flwwc ...再次顯示兩個子進程。
另外，如果從另一個終端在 while 循環中通過writevtI send Ctrl-C等在盡可能短的連續時間內，沒有幫助。
沒有辦法以正常方式阻止瘋狂的狂歡。
我知道的唯一方法就是殺死破碎的bash。但這會導致丟失 bash 歷史記錄。
（對於其他應用程序，我使用 bash PROMPT_COMMAND ... 來 make history -a，但這不是這裡的項目）。
有人知道 bash 這種行為的原因以及如何防止這種新行為嗎？
答案1
找到解釋和解決方案：
上次我正在用各種類型的 PROMPT_COMMAND 進行實驗，以便另外寫入歷史檔案/dev/pts/nn。
錯誤的程式碼是測試中 PROMPT_COMMAMD 的一個元件。
因此，在殺死子進程後，一切似乎都正常，確實一切正常。
然後，當我在損壞的 bash 中給出導致新提示的內容時，在 PROMPT_COMMAND 中執行了錯誤的程式碼。因此子進程被再次創建，等等。
解決方案是：給損壞的 bash 命令
unset PROMPT_COMMAND
然後 bash 的「瘋狂」就停止了。
所以我可以刪除我的問題。但我不這樣做，因為有些觀點值得其他人閱讀，特別是有一點應該公開：
Linux 中的指令很重要writevt。它應該被重新發明，成為每個 Linux 發行版的常規命令。