Subject: Re: Unixism, pipes and pkgsrc
To: Jan Danielsson <jan.m.danielsson@gmail.com>
From: matthew sporleder <msporleder@gmail.com>
List: netbsd-users
Date: 08/21/2007 11:09:14
On 8/21/07, Jan Danielsson <jan.m.danielsson@gmail.com> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
>
> Hello all,
>
> I'm trying to understand something about redirections.
>
> A long time ago, I learned that Unix applications use stdout and
> stderr for output. I also learned that > causes a redirection to a file.
> Pretty soon I found that some output wasn't redirected to the file, but
> that 2> or 2>&1 would solve that.
>
> When I build packages, I use a script which rebuilds outdated
> packages in a chroot. Since these are batch jobs, I don't really see
> what packages have failed. I added support in my rebuild-script to make
> not of which packages failed. But that wasn't very helpful, since I need
> the error messages. So, I tried to redirect stderr to stdout (2>&1), and
> redirect stdout to a log-file when I call "make package".
>
> To my surprise, I still see a lot of output to the screen (though not
> even close to how much it's without the redirections). What's worse, the
> really relevant errors which cause packages to fail seem to be written
> to the terminal through other means that through the processes which
> have their terminal output redirected. For most packages, in my build
> log, I can see that it (make) has tried to execute a command, and that
> it failed. But but the actual error.
>
> For instance: emulators/qemu, games/scummvm
>
> chat/pidgin-silc also fails. Part of the error is only visible on
> screen, but it also writes some informational messages to my redirected
> file handles.
>
> Could someone explain why the shell redirections don't work? Also
> could someone explain how I can get all the build error messages to a
> log file?
>
It's possible to open extra handles. (3 - 9, I think.) Or it might
be giving output from some other exec-ed command that didn't get your
redirection instructions. Try adding some -x's to the build script to
get a better idea of who's opening what.