¿Cómo obtener salida en tiempo real del script, escrito en la sección% post del archivo .spec RPM?

Buen día. Problema: en una sección de% post instalación del archivo de especificaciones RPM puede haber un script. Quiero poner un script con una salida en tiempo real, como la barra de progreso para el proceso posterior a la instalación. Pero toda la salida producida por los comandos en esta sección está fuertemente protegida por (supongo) Yum, y se muestra solo cuando la sección se ejecuta por completo. Pregunta: ¿hay alguna manera de obtener resultados, producidos por scripts dentro de% post secciones (python o scripts de pash puro) de forma inmediata o lo antes posible?

Gracias por adelantado.

— J. Keker
fuente

RPM no es interactivo. Realmente no deberías producir ningún resultado como la barra de progreso. Solo confundirá las herramientas construidas sobre las rpm. Y muy probablemente conducirá a otros errores.

— msuchy

@msuchy Sé que es una mala idea. Pero al menos no trato de hacer cosas realmente interactivas, como obtener la entrada del usuario. La parte principal de la instalación de mi RPM se ahogó en la secuencia de comandos% posterior a la instalación, por lo que era importante ver el progreso y los errores que ocurrían durante la publicación%. Como descubrí más tarde, es posible hacer la salida en stderr. No está amortiguado como stdout. De todos modos, ya redirigí mi salida al archivo de registro. Gracias por una respuesta!

— J. Keker

Aunque el póster original mencionaba una stderrsolución alternativa, yum3.4.3 también parece amortiguarse stderr.

— szmoore

Hay muy buenas razones para mostrar resultados durante una instalación RPM. El hecho de que RPM sea "no interactivo" no tiene relevancia. Si uno de los scriptlets (pre, post, etc.) tarda mucho tiempo, el usuario debe recibir actualizaciones periódicas para saber que el proceso no se ha estancado.

— musaraña

Respuestas:

Puede redirigir stdoutsu secuencia de comandos al stdoutproceso principal. Del mismo modo para stderr.

#!/bin/bash
exec 1>/proc/$PPID/fd/1
exec 2>/proc/$PPID/fd/2

Redirigir de stdoutesta manera podría tener consecuencias no deseadas o dar una desagradable sorpresa a alguien que ejecuta el script tratando de capturar y analizar su stdoutcuando la salida aparece en su terminal de todos modos.

Puede ver cómo esto puede ser confuso (imagine que se ejecuta en un script, no en un -cargumento)

$ x=$(bash -c 'exec 1>/proc/$PPID/fd/1 && echo text')
text
$ echo "x was $x"
x was

En primer lugar, ¡algo impreso aunque la subshell debería haber capturado stdout! Y luego, xestaba vacío! Locura. Parece que textvino de un stderr, excepto que no lo hizo.

Lo ideal yumsería tener una bandera para esto; tal vez alguien debería hacer una solicitud de extracción;)

— szmoore
fuente

Probablemente debería admitir que, aunque advertí que es una mala idea, en realidad siempre lo uso en mis propios scripts de rpm ahora ...

— szmoore

use la redirección a / dev / tty:

program >/dev/tty

— Arte
fuente