Here's one way to fix it.
Since there were so many occurrences, I chose to encapsulate
the test (and not expose/document the new macro).
I admit that this not a big deal, but even when I interrupt a configure
script, I prefer to see it die cleanly. Otherwise, I have to wonder
if some clean-up tra
Hi Jim,
* Jim Meyering wrote on Mon, Aug 18, 2008 at 11:23:01AM CEST:
> I admit that this not a big deal, but even when I interrupt a configure
> script, I prefer to see it die cleanly. Otherwise, I have to wonder
> if some clean-up trap code also fails to run.
>
> Comments, suggestions ?
Doesn
Ralf Wildenhues <[EMAIL PROTECTED]> wrote:
> Hi Jim,
>
> * Jim Meyering wrote on Mon, Aug 18, 2008 at 11:23:01AM CEST:
>> I admit that this not a big deal, but even when I interrupt a configure
>> script, I prefer to see it die cleanly. Otherwise, I have to wonder
>> if some clean-up trap code als
* Jim Meyering wrote on Mon, Aug 18, 2008 at 12:12:29PM CEST:
> Ralf Wildenhues <[EMAIL PROTECTED]> wrote:
> >
> > Doesn't this patch hide potential typos otherwise exposed by the `test'
> > error? AIUI gnulib uses this idiom a lot.
>
> Good point!
> Here's an incremental to fix that:
I don't se
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Jim Meyering on 8/18/2008 3:23 AM:
> Here's one way to fix it.
> Since there were so many occurrences, I chose to encapsulate
> the test (and not expose/document the new macro).
>
> Subject: [PATCH] AC_VAR_YES: new function, to handle an
Ralf Wildenhues <[EMAIL PROTECTED]> wrote:
> * Jim Meyering wrote on Mon, Aug 18, 2008 at 12:12:29PM CEST:
>> Ralf Wildenhues <[EMAIL PROTECTED]> wrote:
>> >
>> > Doesn't this patch hide potential typos otherwise exposed by the `test'
>> > error? AIUI gnulib uses this idiom a lot.
>>
>> Good point
* Jim Meyering wrote on Mon, Aug 18, 2008 at 03:59:18PM CEST:
> Ralf Wildenhues <[EMAIL PROTECTED]> wrote:
>
> > Maybe all you want to prevent is errors from inside the trap code?
>
> No, I want to avoid the parse error.
We are talking past each other. I'm arguing that the parse error is
typica
Ralf Wildenhues gmx.de> writes:
> We are talking past each other. I'm arguing that the parse error is
> typically helpful, not harmful.
>
> Bruno does in several places in gnulib:
>
> # Long computation that sets gl_cv_XXX
> ...
> if test $gl_cv_XXX ...; then
> ...
There's a differe
Ralf Wildenhues <[EMAIL PROTECTED]> wrote:
> * Jim Meyering wrote on Mon, Aug 18, 2008 at 03:59:18PM CEST:
>> Ralf Wildenhues <[EMAIL PROTECTED]> wrote:
>>
>> > Maybe all you want to prevent is errors from inside the trap code?
>>
>> No, I want to avoid the parse error.
>
> We are talking past eac
Eric Blake <[EMAIL PROTECTED]> writes:
> $ ksh -c 'if test `sleep 5; echo hi` = hi ; then echo yes; fi'
> ^Cksh: test: hi: unexpected operator/operand
I've also observed this problem. More generally, I've seen ^C not
interrupt 'configure' scripts properly, in ways other than what Jim is
fixing h
Hello again,
first, sorry for being a bit blunt earlier.
* Jim Meyering wrote on Mon, Aug 18, 2008 at 05:17:22PM CEST:
>
> Yes, I am familiar with that idiom (I've been writing
> autoconf macros that use it for over 12 years).
> However, no code like that is affected, since it is not using
> "te
Ralf Wildenhues <[EMAIL PROTECTED]> wrote:
> Hello again,
>
> first, sorry for being a bit blunt earlier.
No apology needed ;-)
...
>> It appears that what Jim is seeing is that the shell (which one?)
>> catches the Ctrl-C, aborts the subshell, but then proceeds with
>> execution of the builtin t
Ralf Wildenhues gmx.de> writes:
> > $ sh -c 'if test `sleep 5; echo hi` = hi ; then echo yes; fi'
>
> and found only pdksh and OpenBSD sh (which is a pdksh descendant) to
> have this issue.
Jim's original error message does not look the same as pdksh; it reminds me
more of what bash would outp
* Eric Blake wrote on Mon, Aug 18, 2008 at 11:59:22PM CEST:
> Ralf Wildenhues gmx.de> writes:
>
> > > $ sh -c 'if test `sleep 5; echo hi` = hi ; then echo yes; fi'
> >
> > and found only pdksh and OpenBSD sh (which is a pdksh descendant) to
> > have this issue.
>
> Jim's original error message
* Jim Meyering wrote on Mon, Aug 18, 2008 at 11:57:45PM CEST:
> Ralf Wildenhues <[EMAIL PROTECTED]> wrote:
> >> I think we can factor it into a simpler testcase. I just tried this:
> >>
> >> $ sh -c 'if test `sleep 5; echo hi` = hi ; then echo yes; fi'
> >
> > and found only pdksh and OpenBSD sh (
Ralf Wildenhues gmx.de> writes:
>
> (better: I can't reproduce them with that, with a number of shells),
> which means the number of currently known-problematic places in Autoconf
> code is quite small, I found one in status.m4 and one in the test suite.
Thanks for the audit.
>
> This is what
Hi Eric,
* Eric Blake wrote on Tue, Aug 19, 2008 at 10:52:46PM CEST:
> Ralf Wildenhues gmx.de> writes:
>
> > I'm pretty sure that any remaining test failure I'm seeing are not
> > introduced by this patch, so if you are ok with it I'll apply.
>
> Any help I can offer on tracking down the (unrel
Ralf Wildenhues <[EMAIL PROTECTED]> wrote:
> * Jim Meyering wrote on Mon, Aug 18, 2008 at 11:57:45PM CEST:
>> Ralf Wildenhues <[EMAIL PROTECTED]> wrote:
>> >> I think we can factor it into a simpler testcase. I just tried this:
>> >>
>> >> $ sh -c 'if test `sleep 5; echo hi` = hi ; then echo yes;
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Ralf Wildenhues on 8/18/2008 5:09 PM:
>> I know that when testing my m4_transform_pair patch, I was able to trip an
>> arbitrary limit in bash - it refuses to parse more than 2500 nested elif
>> keywords inside an if/else/fi. I wonder i
* Eric Blake wrote on Tue, Aug 19, 2008 at 06:22:40AM CEST:
> According to Ralf Wildenhues on 8/18/2008 5:09 PM:
> >
> > Ahh, thanks for this hint. It is indeed weird that I can trip the
> > failure of test 50 with './testsuite 59-60' or './testsuite 60' but not
> > with './testsuite 59-61'. So I
20 matches
Mail list logo
