Bash perpetually generates child processes and cannot be stopped. What is happening?

Question

In Kubuntu 20.04 or KNOPPIX 9.1, in KDE under Konsole many windows and in each bash ver 5.2.15(1)-release (i686-pc-linux-gnu).

The problem describe in this question I had come up often in the last few weeks (but never before).

Always it is caused by a wrong command line in a sourced script or typed after shell prompt.

Sometimes (not today) bash endlessly forks new processes.

Today I can report the false command line which is the cause -- it is not literally what I typed, it is what ps shows:

ps -Flwwc -t pts/14

ps shows in column "CMD":

sed -r eval s=(.*)=\1; ZZZZZZZZZ;=p /root/.bash_history

Please note that this false command is not the item of my question (I know what I am trying and what the next steps are).

The item is, what the crazy bash does and what the help is.

bash shows these two lines in an endless succession:

sh -c: line 1: syntax error near unexpected token `('

sh -c: line 1: `val s=(.*)=1; ZZZZZZZZZ;=p'

In another terminal's bash I run

ps -Flwwc --sort=start_time -t pts/14

and I see that two child processes are active:

1. sed (as shown above)
2. less

The PPID of both is the broken bash.

In the broken bash there is no means. E.g.

Typing Return brings less with its contents. Closing less, I am in the bash prompt, as if all would be ok. And in the other terminal ps -Flwwc ... shows as if all would be ok: the two child processes are vanished, the bottom process is the broken bash.

Now back in the broken bash: if I type Return or if I type Ctrl-C, I get the endless sequence of the two lines and in the other terminal ps -Flwwc ... shows the two child processes again.

Also if from another terminal in a while loop via writevt I send Ctrl-C etc. in a shortest possible succession, no help.

There is no way to stop the crasy bash in a normal manner.

The only way I know is to kill the broken bash. But this causes to loose the bash history.

( for other applications I use bash PROMPT_COMMAND ... to make history -a, but that is not the item here).

Does someone know the reason for this behavior of bash and how to prevent this new behavior?

Answer 1

Found explanation and solution:

In last times I am making experiments with various kinds of PROMPT_COMMAND in order into the history file additionally /dev/pts/nn to be written.

The wrong code was a component of the PROMPT_COMMAMD in test.

Thus after killing the child processes it seems all to be normal, indeed all was normal.

When then in the broken bash I gave something that caused a new prompt, the wrong code was execuded within the PROMPT_COMMAND. And thus the child processes were created again, etc.

The solution is: to give the broken bash the command

unset PROMPT_COMMAND

Then the "craziness" of bash ceases.

So I could delete my question. But I do not because some points are worth to be read by others, especially one point should remain public:

It is important to have in Linux the command writevt. It should be re-invented to be normal command of every Linux distribution.