Concern about new g-b-s logging change - loss of error detection

Igor Pechtchanski
Sun Nov 20 15:18:00 GMT 2005

On Sat, 19 Nov 2005, Max Bowsher wrote:

> This thread seems to have gone to sleep.

Sorry -- it was sitting in my "Follow-Up" folder, but I somehow didn't get
to reply to this.

> Summary: The addition of the 'logging' g-b-s feature introduced a bug:
> Errors during phases of package building do not halt the build, so that
> an error during 'make' or 'make install' would not prevent the 'pkg'
> operation running, and producing flawed package files.
> If no one has time to fix the logging feature properly right now, could
> we just revert the logging feature from g-b-s CVS HEAD until someone does?

Let's try to come up with a solution (see below), but if we can't very
soon, I'll disable the logging.

> === Full text of earlier part of thread follows: ===
> Max Bowsher wrote:
> > Igor Pechtchanski wrote:
> >
> >> On Sat, 29 Oct 2005, Max Bowsher wrote:
> >>
> >>> Please forgive me if this has already been discussed - I've been
> >>> time-limited to scanning subject lines only recently.
> >>>
> >>> Bourne shells consider only the exit status of the last command in a
> >>> pipeline when determining $? - this means that the addition of lots of
> >>> "| tee somefile" will cause errors occurring during the commands being
> >>> logged to be ignored.
> >>>
> >>> This seems to me to be a more severe problem than not keeping the logs
> >>> in the first place - as a failing "make" could result in the packaging
> >>> of a partially built package.
> >>
> >> Max,
> >>
> >> Thanks for bringing this up.  This hasn't been discussed, and I admit
> >> I missed this aspect of the problem when reviewing the patch.  I did
> >> have a fleeting thought of changing the "tee"s to redirections, but
> >> didn't realize the importance of this.  I just verified that even
> >> with "set -e" in effect, bash will not terminate if an interior pipe
> >> command fails.
> >>
> >> I can think of two ways to tackle this: use redirection (with the
> >> loss of immediate console output),
> >
> > I don't like that idea. When building a large package, this would mean
> > many minutes without any feedback at all.

Agreed.  I just wanted to bring this up for completeness.

> >> or use $PIPESTATUS (which is a bashism, and is fragile, unless we use
> >> ${PIPESTATUS[$((${#PIPESTATUS[@]}-1))]}).
> >
> > I think using a bashism is OK. Even people who don't actually use bash
> > interactively will have it installed - it's in 'Base', after all.

So, we make g-b-s a /usr/bin/bash script instead of /bin/sh script?  Are
there any objections to this?  Is this script ever used in any (e.g.,
cross-compilation) environments where /bin/sh is *not* bash?

> > Why would ${PIPESTATUS[1]} not be OK?

Because that would only work for cases where the only pipe is added by
logging (i.e., fragile).  If someone ever wanted to pipe something to
configure in that step, whoever made the change would need to know to
change ${PIPESTATUS[1]} to ${PIPESTATUS[2]}, which is too easy to miss
(i.e., fragile).  I'm willing to be convinced that I'm being paranoid
here, though.
      |\      _,,,---,,_
ZZZzz /,`.-'`'    -.  ;-;;,_
     |,4-  ) )-,_. ,\ (  `'-'		Igor Pechtchanski, Ph.D.
    '---''(_/--'  `-'\_) fL	a.k.a JaguaR-R-R-r-r-r-.-.-.  Meow!

If there's any real truth it's that the entire multidimensional infinity
of the Universe is almost certainly being run by a bunch of maniacs. /DA

More information about the Cygwin-apps mailing list