How to get real time output of script, written in %post section of RPM .spec file?

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.

J. Keker

Posted 2016-12-10T05:36:06.123

Reputation: 21

2RPM 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 – 2016-12-13T13:28:34.977

@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 – 2016-12-16T17:39:48.183

Although the original poster mentioned a stderr workaround, yum 3.4.3 seems to buffer stderr as well. – szmoore – 2018-09-27T06:00:12.753

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 – 2018-11-16T16:26:34.053

Answers

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 ;)

szmoore

Posted 2016-12-10T05:36:06.123

Reputation: 111

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 – 2019-01-08T01:56:02.283

use redirection to /dev/tty:

program >/dev/tty

art

Posted 2016-12-10T05:36:06.123

Reputation: 1