Re: Concern about new g-b-s logging change - loss of error detection
On Sun, 20 Nov 2005, Max Bowsher wrote:
> Igor Pechtchanski wrote:
>
> > Let's try to come up with a solution (see below), but if we can't very
> > soon, I'll disable the logging.
>
> Good.
>
> or use $PIPESTATUS (which is a bashism, and is fragile, unless we use
> ${PIPESTATUS[$(([EMAIL PROTECTED]))]}).
> >>>
> >>>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?
>
> Bash usually lives in /bin, not /usr/bin.
On Linux it does. If bash lives in /bin, it's standard on the system and
I'm not worried about those systems. I'm guessing I'm just overcautious.
> I would think that any Linux system featureful enough to have a
> compiler, would have a /bin/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.
>
> Hang on: It is the *first* item in the pipe (the real command) that we
> care about, anyway, not any filters placed after it. So,
> ${PIPESTATUS[0]}, and we don't need to worry about people adding to the
> end of the pipe.
Nope, that's why I said "piping something *to* configure", not "piping
configure output into something". The thing we're interested in may not
be the first item in the pipe (in fact, to preserve the behavior we had
before the logging change, we'd need to consider the return code of the
last pipe stage). Whether that's the correct behavior is a separate
question, which also needs to be addressed...
Igor
--
http://cs.nyu.edu/~pechtcha/
|\ _,,,---,,_[EMAIL PROTECTED]
ZZZzz /,`.-'`'-. ;-;;,_[EMAIL PROTECTED]
|,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
Re: Concern about new g-b-s logging change - loss of error detection
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Igor Pechtchanski wrote:
> On Sat, 19 Nov 2005, Max Bowsher wrote:
>
>>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.
Good.
...
or use $PIPESTATUS (which is a bashism, and is fragile, unless we use
${PIPESTATUS[$(([EMAIL PROTECTED]))]}).
>>>
>>>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?
Bash usually lives in /bin, not /usr/bin.
I would think that any Linux system featureful enough to have a
compiler, would have a /bin/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.
Hang on: It is the *first* item in the pipe (the real command) that we
care about, anyway, not any filters placed after it. So,
${PIPESTATUS[0]}, and we don't need to worry about people adding to the
end of the pipe.
Max.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (Cygwin)
iD8DBQFDgLCgfFNSmcDyxYARAsbmAKCQi6Zk4Ey6zp4j5qe2Ravp6Tl9qACfcfIj
B8RJBVTLT5z9//YcvnXPBwI=
=NTyg
-END PGP SIGNATURE-
Re: Concern about new g-b-s logging change - loss of error detection
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[$(([EMAIL PROTECTED]))]}).
> >
> > 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.
Igor
--
http://cs.nyu.edu/~pechtcha/
|\ _,,,---,,_[EMAIL PROTECTED]
ZZZzz /,`.-'`'-. ;-;;,_[EMAIL PROTECTED]
|,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
Re: Concern about new g-b-s logging change - loss of error detection
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
This thread seems to have gone to sleep.
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?
Thanks,
Max.
=== 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.
>
>> or use $PIPESTATUS (which is a bashism, and is
>> fragile, unless we use ${PIPESTATUS[$(([EMAIL PROTECTED]))]}).
>
>
> 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.
>
> Why would ${PIPESTATUS[1]} not be OK?
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (Cygwin)
iD8DBQFDf2/KfFNSmcDyxYARAuPZAJwIi7o6tswK4MiM6gSW47CJaMM53QCeNT4R
Y1VhvWqxw4sgxZ98GMBuFBE=
=IvkU
-END PGP SIGNATURE-
Re: Concern about new g-b-s logging change - loss of error detection
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.
or use $PIPESTATUS (which is a bashism, and is
fragile, unless we use ${PIPESTATUS[$(([EMAIL PROTECTED]))]}).
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.
Why would ${PIPESTATUS[1]} not be OK?
Max.
Re: Concern about new g-b-s logging change - loss of error detection
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), or use $PIPESTATUS (which is a bashism, and is
fragile, unless we use ${PIPESTATUS[$(([EMAIL PROTECTED]))]}). Any
other suggestions?
Igor
--
http://cs.nyu.edu/~pechtcha/
|\ _,,,---,,_[EMAIL PROTECTED]
ZZZzz /,`.-'`'-. ;-;;,_[EMAIL PROTECTED]
|,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
