Este equipo de especialistas luego de algunos días de investigación y de recopilar de datos, han obtenido los datos necesarios, deseamos que todo este artículo sea de utilidad para tu plan.
Solución:
los nohup el comando solo escribe en nohup.out si la salida iría de otra manera a la terminal. Si ha redirigido la salida del comando a otro lugar, incluido /dev/null – ahí es donde va en su lugar.
nohup command >/dev/null 2>&1 # doesn't create nohup.out
Si estas usando nohup, eso probablemente significa que desea ejecutar el comando en segundo plano poniendo otro & al final de todo:
nohup command >/dev/null 2>&1 & # runs in background, still doesn't create nohup.out
En Linux, ejecutar un trabajo con nohup también cierra automáticamente su entrada. En otros sistemas, especialmente BSD y macOS, ese no es el caso, por lo que cuando se ejecuta en segundo plano, es posible que desee cerrar la entrada manualmente. Si bien el cierre de la entrada no tiene ningún efecto sobre la creación o no de nohup.out, evita otro problema: si un proceso en segundo plano intenta leer algo de la entrada estándar, se detendrá, esperando a que lo devuelva al primer plano y escriba algo. Entonces, la versión extra segura se ve así:
nohup command /dev/null 2>&1 & # completely detached from terminal
Sin embargo, tenga en cuenta que esto no impide que el comando acceda directamente al terminal, ni lo elimina del grupo de procesos de su shell. Si desea hacer lo último y está ejecutando bash, ksh o zsh, puede hacerlo ejecutando disown sin argumento como siguiente comando. Eso significará que el proceso en segundo plano ya no está asociado con un “trabajo” de shell y no se le enviarán señales desde el shell. (Nótese la distinción: un disownEl proceso ed no recibe señales automáticamente enviadas por su shell padre, pero sin nohup, seguirá recibiendo un HUP señal enviada a través de otros medios, como un manual kill mando. A nohupEl proceso ed ignora todos y cada uno HUP señales, no importa cómo se envíen).
Explicación:
En los sistemas Unixy, cada fuente de entrada o destino de salida tiene un número asociado llamado “descriptor de archivo”, o “fd” para abreviar. Cada programa en ejecución (“proceso”) tiene su propio conjunto de estos, y cuando se inicia un nuevo proceso, ya tiene tres abiertos: la “entrada estándar”, que es fd 0, está abierta para que el proceso lea, mientras que La “salida estándar” (fd 1) y el “error estándar” (fd 2) están abiertos para que pueda escribir. Si solo ejecuta un comando en una ventana de terminal, entonces, de forma predeterminada, todo lo que escriba va a su entrada estándar, mientras que tanto su salida estándar como el error estándar se envían a esa ventana.
Pero puede pedirle al shell que cambie el punto en el que apuntan alguno o todos esos descriptores de archivo antes de ejecutar el comando; eso es lo que la redirección<, <<, >, >>) y tubería (|) lo hacen los operadores.
La pipa es la más simple de estas ... command1 | command2 organiza la salida estándar de command1 para alimentar directamente en la entrada estándar de command2. Esta es una disposición muy útil que ha llevado a un patrón de diseño particular en las herramientas de UNIX (y explica la existencia de un error estándar, que permite que un programa envíe mensajes al usuario aunque su salida vaya al siguiente programa en la tubería) . Pero solo puede canalizar la salida estándar a la entrada estándar; no puede enviar ningún otro descriptor de archivo a una tubería sin hacer algunos malabarismos.
Los operadores de redirección son más amigables porque le permiten especificar qué descriptor de archivo redireccionar. Entonces 0infile, tiempo 2>>logfile agrega el error estándar al final del archivo llamado logfile. Si no especifica un número, la redirección de entrada predeterminada es fd 0 (< es lo mismo que 0<), mientras que la redirección de salida tiene como valor predeterminado fd 1 (> es lo mismo que 1>).
Además, puede combinar descriptores de archivos juntos: 2>&1 significa "enviar error estándar dondequiera que vaya la salida estándar". Eso significa que obtiene un único flujo de salida que incluye tanto la salida estándar como el error estándar entremezclados sin forma de separarlos más, pero también significa que puede incluir el error estándar en una tubería.
Entonces la secuencia >/dev/null 2>&1 significa "enviar salida estándar a /dev/null"(que es un dispositivo especial que simplemente desecha todo lo que escribe)" y luego envía el error estándar a donde sea que vaya la salida estándar "(que nos aseguramos de que fuera /dev/null). Básicamente, "deseche todo lo que este comando escriba en cualquiera de los descriptores de archivo".
Cuando nohup detecta que ni su error estándar ni su salida están conectados a un terminal, no se molesta en crear nohup.out, pero asume que la salida ya está redirigida a donde el usuario quiere que vaya.
los /dev/null el dispositivo también funciona para la entrada; si ejecuta un comando con , entonces cualquier intento de ese comando de leer desde la entrada estándar encontrará instantáneamente el final del archivo. Tenga en cuenta que la sintaxis de fusión no tendrá el mismo efecto aquí; solo funciona para apuntar un descriptor de archivo a otro que está abierto en la misma dirección (entrada o salida). El caparazón te dejará hacer >/dev/null <&1, pero eso termina creando un proceso con un descriptor de archivo de entrada abierto en un flujo de salida, por lo que en lugar de simplemente presionar el final del archivo, cualquier intento de lectura desencadenará un error fatal de "descriptor de archivo no válido".
nohup some_command > /dev/null 2>&1&
¡Eso es todo lo que necesitas hacer!
¿Ha intentado redirigir las tres corrientes de E / S?
nohup ./yourprogram > foo.out 2> foo.err < /dev/null &
Sección de Reseñas y Valoraciones
Si te animas, tienes el poder dejar un artículo acerca de qué te ha parecido este tutorial.