2

Good day. Problem: In a %post install section of RPM spec file can be a script. I want to put there a script with a realtime output, like progress bar for post-installation process. But all output produced by commands in this section is strongly buffered by (i suppose) Yum, and showed only when section is completely executed. Question: is there a way to get output, produced by scripts inside of %post sections (python or pure pash scripts) imidiately or asap?

Thanks in advance.

4
  • 2
    RPM is noninteractive. You really should not produce any output like progress bar. It will just confuse tools built on top of rpm. And it will very likely lead to some other errors.
    – msuchy
    Dec 13, 2016 at 13:28
  • @msuchy I know that is sort of bad idea. But at least i don't try to do realy interactive things, like getting user input. Main installation part of my RPM was drowned into %post install script, so it was important to see progress and errors occuring during %post. As i discovered later, it's possible to do output in stderr. It's not bufferized like stdout. Anyway, already rerouted my output to log file. Thanks for a reply!
    – J. Keker
    Dec 16, 2016 at 17:39
  • Although the original poster mentioned a stderr workaround, yum 3.4.3 seems to buffer stderr as well.
    – szmoore
    Sep 27, 2018 at 6:00
  • There are very good reasons for showing output during an RPM installation. The fact that RPM is "noninteractive" has no relevance. If one of the scriptlets (pre, post, etc) takes a long time the user should get periodic updates in order to know that the process hasn't stalled.
    – shrewmouse
    Nov 16, 2018 at 16:26

2 Answers 2

2

You can redirect stdout of your script to the stdout of its parent process. Similarly for stderr.

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

Redirecting stdout like this could have unintended consequences or give a nasty surprise to someone running the script trying to capture and parse its stdout when that output appears in their terminal anyway.

You can see how this might be confusing (imagine its running on a script not a -c argument)

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

Firstly, something printed even though the subshell should have captured stdout! And then, x was empty! Madness. It looks like the text came from a stderr, except it didn't.

Ideally yum would just have a flag for this; maybe someone should make a pull request ;)

2
  • I should probably admit that even though I warned this is a bad idea I do actually always use it in my own rpm scripts now...
    – szmoore
    Jan 8, 2019 at 1:56
  • Bonus hack: Use ps --no-headers -o ppid:1 and iterate through the output fds until you find one for which dirname $(realpath /proc/$PID/fd/1) == "/dev/pts" - Then no matter what, your output will always annoy someone.
    – szmoore
    Feb 25, 2021 at 7:51
0

use redirection to /dev/tty:

program >/dev/tty

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .