linux - mac - ¿Cómo funciona "while(sleep 100 &!) Do; hecho "trabajo en zsh, y ¿cómo podría ser replicado en bash?

zsh update

Question

Según Wikipedia , la bomba de horquilla :(){ :|:& };: se puede detener con el comando zsh while (sleep 100 &!) do; done while (sleep 100 &!) do; done , que supuestamente engendrará 100 procesos de suspensión hasta que todos los procesos de forkbomb se hayan ido. Esto parece magia. ¿como funciona? Tengo especial curiosidad por saber exactamente qué "&!" medio.

¿Cómo se vería un comando equivalente en bash?

Answer 1

La razón por la que funciona una bomba de horquilla es porque hay un límite finito para la cantidad de procesos que se pueden ejecutar en cualquier momento, y una bomba de horquilla está diseñada para llenar este límite.

Debido a que el código forkbomb que proporcionó muere si no puede engendrar un proceso secundario, los procesos principales en realidad no se mantienen, pero el hecho de que los hijos sigan creando nuevos * grand -children mantiene llena la tabla de procesos.

Entonces, la solución para dormir está diseñada para colarse en algunos procesos que solo duermen durante un corto período de tiempo, y para cada proceso de sueño que se logra crear, hay menos bombas de horquilla. Finalmente, los procesos de sueño llenan la tabla de procesamiento y las bombas de horquilla mueren.

Una vez que la tabla de procesos está llena, Sleep Process procesa el ciclo de while y puede perder los procesos de suspensión una vez que se agota el tiempo de espera. Problema resuelto

Como ya se mencionó, la parte importante del comando zsh es el run-in-background & , por lo que el comando bash sería básicamente el mismo que se da en las otras respuestas:

while (sleep 100 &) do; done

No creo que el nohup / ! la parte es importante, a menos que quieras desconectarte dentro del tiempo de suspensión, pero me gustaría que me aclaren si estoy equivocado.

Answer 2

Pregunta muy interesante!

Según ese artículo de Wikipedia, el propósito del comando completo es crear muchos trabajos inofensivos que deshabilitarán la bomba de la horquilla porque ya no podrá engendrar más niños.

De acuerdo con el manual de zsh ,

Si un trabajo se inicia con &|'' or &|'' or &! '', entonces ese trabajo es inmediatamente repudiado. Después del inicio, no tiene un lugar en la tabla de trabajo y no está sujeto a las funciones de control de trabajo que se describen aquí.

No estoy seguro de cómo lograr lo mismo con bash. Sin embargo, algo como lo siguiente podría hacer:

nohup sleep 100 &

Answer 3

Primero, la bomba de la horquilla puede escribirse:

foo()
{
foo|foo&
}
foo

Lo que lo hace un poco más claro: cada iteración comienza dos subprocesos, luego muere. Entonces, si la bifurcación falla, no se mantendrá.

Por lo tanto, todo lo que tenemos que hacer es hacer que la bifurcación falle temporalmente. Por lo tanto, creamos procesos que duermen 100 y ocupan espacio de proceso, como lo hacen los procesos de suspensión.

El zsh &! es como & pero descarta el nuevo proceso (no lo mata al cerrar la sesión) - probablemente no sea importante en este ejemplo. ( manual ) Se puede reemplazar con nohup .

Por lo tanto, el bash:

while (nohup sleep 100 &) do; done

Deberia trabajar.

Answer 4

¡Soy el tipo que escribió esa parte del artículo de Wikipedia (y que "descubrió" esta cura después de poner accidentalmente la bomba de horquilla en mi sistema!).

El motivo de "&" en lugar de "&" es para evitar que zsh haga control del trabajo sobre el nuevo proceso, es decir, tratando de importar cuándo y si terminó. No recuerdo exactamente por qué el control del trabajo era un problema cuando lo probé, pero lo fue. De hecho, puede intentarlo para ver cómo funciona la "cura" y qué sucede si no evita el control del trabajo. Tal vez el problema con el control del trabajo tuvo que ver con algún error en zsh que ni siquiera existe en bash, y tal vez ya no es relevante en zsh.

Así que intente solo con un "y" con bash, y si el control del trabajo está interfiriendo, intente desactivarlo ("set + m") y con suerte esto funcionaría.

Tienes razón en que el artículo de wikipedia probablemente no debería ser zsh dependiente.