En Kubuntu 20.04 o KNOPPIX 9.1, en KDE bajo Konsole muchas ventanas y en cada bash versión 5.2.15(1) (i686-pc-linux-gnu).
El problema descrito en esta pregunta me había surgido con frecuencia en las últimas semanas (pero nunca antes).
Siempre es causado por una línea de comando incorrecta en un script de origen o escrita después del símbolo del shell.
A veces (no hoy) bash bifurca interminablemente nuevos procesos.
Hoy puedo informar la línea de comando falsa que es la causa; no es literalmente lo que escribí, es lo que ps muestra:
ps -Flwwc -t pts/14
ps muestra en la columna "CMD":
sed -r eval s=(.*)=\1; ZZZZZZZZZ;=p /root/.bash_history
Tenga en cuenta que este comando falso no es el elemento de mi pregunta (sé lo que estoy intentando y cuáles son los próximos pasos).
El tema es qué hace el Crazy Bash y cuál es la ayuda.
bash muestra estas dos líneas en una sucesión interminable:
sh -c: line 1: syntax error near unexpected token `('
sh -c: line 1: `val s=(.*)=1; ZZZZZZZZZ;=p'
En el bash de otra terminal ejecuto
ps -Flwwc --sort=start_time -t pts/14
y veo que dos procesos secundarios están activos:
sed(como se muestra arriba)less
El PPID de ambos es el bash roto.
En una fiesta rota no hay medios. P.ej
Escribir Returnaporta menos con su contenido. Al cerrar menos, estoy en el indicador de bash, como si todo estuviera bien. Y en la otra terminal ps -Flwwc ...se muestra como si todo estuviera bien: los dos procesos secundarios desaparecieron, el proceso inferior es el bash roto.
Ahora, de vuelta en el bash roto: si escribo Returno si escribo Ctrl- C, obtengo la secuencia interminable de las dos líneas y en la otra terminal ps -Flwwc ...muestro los dos procesos secundarios nuevamente.
Además, si desde otro terminal en un bucle while writevtenvío Ctrl, Cetc. en la sucesión más corta posible, no hay ayuda.
No hay forma de detener el loco ataque de manera normal.
La única forma que conozco es matar el bash roto. Pero esto hace que se pierda el historial de bash.
(para otras aplicaciones uso bash PROMPT_COMMAND... para crear history -a, pero ese no es el elemento aquí).
¿Alguien sabe el motivo de este comportamiento de bash y cómo prevenir este nuevo comportamiento?
Respuesta1
Explicación encontrada y solución:
Últimamente estoy haciendo experimentos con varios tipos de PROMPT_COMMAND para poder /dev/pts/nnescribirlo adicionalmente en el archivo de historial.
El código incorrecto era un componente de PROMPT_COMMAMD en la prueba.
Así, después de matar los procesos infantiles, todo parece normal; de hecho, todo era normal.
Cuando en el bash roto di algo que provocó un nuevo mensaje, se ejecutó el código incorrecto dentro de PROMPT_COMMAND. Y así se crearon nuevamente los procesos secundarios, etc.
La solución es: darle el comando al bash roto.
unset PROMPT_COMMAND
Entonces cesa la "locura" de bash.
Entonces podría eliminar mi pregunta. Pero no lo hago porque algunos puntos merecen ser leídos por otros, especialmente un punto debería permanecer público:
Es importante tener en Linux el comando writevt. Debería reinventarse para que sea el comando normal de cada distribución de Linux.