This is the mail archive of the
mailing list for the Cygwin project.
RE: Setup: capturing postinstall output
- From: Bradey Honsinger <BradeyH at construx dot com>
- To: "'cygwin-apps at cygwin dot com'" <cygwin-apps at cygwin dot com>
- Date: Wed, 3 Jul 2002 12:55:08 -0700
- Subject: RE: Setup: capturing postinstall output
Does this seem like a good (or bad) way to go to anyone else (particularly
Robert)? I didn't expect my hacked-up patch to get accepted right off the
bat, but this was a bit of a problem for me, so I'm willing to put more work
into it if I get some feedback.
From: Bradey Honsinger
Sent: Wednesday, June 26, 2002 5:37 PM
Subject: Setup: capturing postinstall output
Being able to run package-specific postinstall scripts is pretty
nifty, but one drawback is that the output of those scripts is
lost. It flickers by in console windows as setup finishes, but that's
pretty much unreadable, at least on my system. Since some packages
(like apache-mod*) aren't really installed unless their postinstall
script succeeds--and the only way to tell whether it succeeded is by
looking at the output--this is kind of a problem.
I searched the list for "postinstall output" and "postinstall log" and
didn't find anything, so I decided to have a go at it myself. Given
the complexity of redirecting child processes' stdin/stdout/stderr
using Win32, it seemed like the simplest solution was to make bash
do the redirection, so I wrote a little script and patched setup to
call it instead of running the postinstall scripts directly. It's a
little less cool than the current implementation--no opportunity to
use the Visitor pattern!--but to my Unix-centric mind, it seems just
The script is pretty simple:
# This is /tmp/run-postinstall.sh
for file in /etc/postinstall/*.sh
echo "Running $file:"
mv $file $file.done
} > /var/log/postinstall.log 2>&1
The patch (which is against setup-188.8.131.52, not the tip) is included below.
It worked for me with an existing Cygwin 1.3.10 install and the script
above in /tmp/run-postinstall.sh (although I had to make some minor
changes to get setup to build). I haven't yet tried it with a 'clean'
There are a couple of considerations:
- This script doesn't run .bat files, while the current code does.
The only .bat postinstall script that I saw was passwd-grp.bat (and I
installed pretty much everything). There's nothing in passwd-grp.bat
that can't go in a shell script, so I just renamed it passwd-grp.sh
(this is included in the patch). Not allowing .bat postinstalls would,
of course, have to be a well-considered policy change by whoever
considers these things.
- The run-postinstall.sh script has to come from somewhere. Since
there isn't a mandatory 'setup' package that could contain it, we'd
either have to make one or write it out from code (like passwd-grp.sh
- This doesn't really solve the problem of failed postinstall
scripts. It would be nice to require postinstall scripts to exit
non-zero if they fail, and then have setup notify the user. This
script does at least allow the user to _detect_ that a postinstall
script failed, though, which is a start.
 Look at
othred_4uus.asp> to see how to redirect a child process's standard
input and output using the Win32 API.