[openssl.org #1085] DJGPP patch for 0.9.8-beta3

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

[openssl.org #1085] DJGPP patch for 0.9.8-beta3

Rich Salz via RT

[[hidden email] - Sun Jun 12 03:21:44 2005]:

> On Mon, 6 Jun 2005, Richard Levitte via RT wrote:
>
> > Whatever the problem is, I do not agree with removing 'set -e'.
>    Setting
> > -e ensures that an error that happens within a loop is propagated to
> > become the error *of* the loop (or actually, the whole shell
>    session),
> > which is therefore returned to make.  Without 'set -e', errors may
> > happen withing the loops or a series of commands with make not
>    knowing
> > about it.  Instead, make will only get the exit code from the last
> > command executed.
>
>
> I guess I just don't understand. I don't see why it succeeds on any
> platform. The "set -e" fails if an exit code is anything other than
> "0". Installing the manual pages involves calling grep with arguments
> known to succeed at times and fail at times, sometimes giving exit
> code of "0" and sometimes of "1". That seems to be why "set -e" stops
> the loop. For example:

Aha, *that's* what we need to debug then.

BTW, the exit code of a pipe is usually the exit code of the last
command in the chain.  So you can't really blame grep, since their
result is piped into a parenthesised complex command.  I'm willing to be
either 'read' or 'util/point.sh' return with an exit code other than 0,
and that it could be enough to have an 'exit 0' at the end of the
complex command (and maybe another 'set -e' before the while loop).

--
Richard Levitte
[hidden email]
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: [openssl.org #1085] DJGPP patch for 0.9.8-beta3

Doug Kaufman
On Mon, 13 Jun 2005, Richard Levitte via RT wrote:

> [[hidden email] - Sun Jun 12 03:21:44 2005]:
>
> > On Mon, 6 Jun 2005, Richard Levitte via RT wrote:
> >
> > > Whatever the problem is, I do not agree with removing 'set -e'.
> >    Setting
> > > -e ensures that an error that happens within a loop is propagated to
> > > become the error *of* the loop (or actually, the whole shell
> >    session),
> > > which is therefore returned to make.  Without 'set -e', errors may
> > > happen withing the loops or a series of commands with make not
> >    knowing
> > > about it.  Instead, make will only get the exit code from the last
> > > command executed.
> >
> >
> > I guess I just don't understand. I don't see why it succeeds on any
> > platform. The "set -e" fails if an exit code is anything other than
> > "0". Installing the manual pages involves calling grep with arguments
> > known to succeed at times and fail at times, sometimes giving exit
> > code of "0" and sometimes of "1". That seems to be why "set -e" stops
> > the loop. For example:
>
> Aha, *that's* what we need to debug then.
>
> BTW, the exit code of a pipe is usually the exit code of the last
> command in the chain.  So you can't really blame grep, since their
> result is piped into a parenthesised complex command.  I'm willing to be
> either 'read' or 'util/point.sh' return with an exit code other than 0,
> and that it could be enough to have an 'exit 0' at the end of the
> complex command (and maybe another 'set -e' before the while loop).
Testing various changes in Makefile reveals that the problem really
does seem to be the return code from grep. This is probably a bug in
the DJGPP implementation of "set -e" in bash, related to the fact that
DOS really doesn't have pipes. They are emulated via temporary files.
The DJGPP "set -e" seems to be sensitive to non-zero return codes
within the simulated pipe. The attached patch to Makefile.org works
for DJGPP. I think it shouldn't adversely affect other platforms.
                              Doug


--
Doug Kaufman
Internet: [hidden email]

Makefile.org.dif (814 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [openssl.org #1085] DJGPP patch for 0.9.8-beta3

Rich Salz via RT
In reply to this post by Rich Salz via RT

On Mon, 13 Jun 2005, Richard Levitte via RT wrote:

> [[hidden email] - Sun Jun 12 03:21:44 2005]:
>
> > On Mon, 6 Jun 2005, Richard Levitte via RT wrote:
> >
> > > Whatever the problem is, I do not agree with removing 'set -e'.
> >    Setting
> > > -e ensures that an error that happens within a loop is propagated to
> > > become the error *of* the loop (or actually, the whole shell
> >    session),
> > > which is therefore returned to make.  Without 'set -e', errors may
> > > happen withing the loops or a series of commands with make not
> >    knowing
> > > about it.  Instead, make will only get the exit code from the last
> > > command executed.
> >
> >
> > I guess I just don't understand. I don't see why it succeeds on any
> > platform. The "set -e" fails if an exit code is anything other than
> > "0". Installing the manual pages involves calling grep with arguments
> > known to succeed at times and fail at times, sometimes giving exit
> > code of "0" and sometimes of "1". That seems to be why "set -e" stops
> > the loop. For example:
>
> Aha, *that's* what we need to debug then.
>
> BTW, the exit code of a pipe is usually the exit code of the last
> command in the chain.  So you can't really blame grep, since their
> result is piped into a parenthesised complex command.  I'm willing to be
> either 'read' or 'util/point.sh' return with an exit code other than 0,
> and that it could be enough to have an 'exit 0' at the end of the
> complex command (and maybe another 'set -e' before the while loop).

Testing various changes in Makefile reveals that the problem really
does seem to be the return code from grep. This is probably a bug in
the DJGPP implementation of "set -e" in bash, related to the fact that
DOS really doesn't have pipes. They are emulated via temporary files.
The DJGPP "set -e" seems to be sensitive to non-zero return codes
within the simulated pipe. The attached patch to Makefile.org works
for DJGPP. I think it shouldn't adversely affect other platforms.
                              Doug


--
Doug Kaufman
Internet: [hidden email]
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       [hidden email]
Automated List Manager                           [hidden email]