[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Another ash braindamage (testsuite only)
From: |
Pavel Roskin |
Subject: |
Re: Another ash braindamage (testsuite only) |
Date: |
Thu, 12 Oct 2000 13:02:51 -0400 (EDT) |
Hello, Akim!
> | The problem is that the code immediately after that relies on $?. In fact,
> | $? is normally (in bash) reset to 0 by executing $at_traceon, which is
> | normally empty because at_traceon is not set.
>
> What code are you referring to? Who is depending upon $? after
> running this? Could you develop?
AT_CHECK (defined in tests/atgeneral.m4) uses to have the following code:
$at_failed && exit 1
at_failed is set initially to "false" and then to ":" if any of diffs
(for stdout or stderr) fails. Now, let's see what happens if both diffs
succeed.
at_failed remains "false", thus we have
false && exit 1
In this case we don't exit, but $? is set to 1 by "false". Now if the
subshell terminates at this point, $? remains 1, which means that
AT_CLEANUP would report an error.
But $at_traceon in the end of AT_CHECK changes $? to 0. Note that
at_traceon is either undefined or defined to "set +vx"
When at_traceon is not defined $? is still cleared in most shells but not
in ash-0.2.
> This should be described in the documentation, along with all the
> limitations you've already discovered :)
Ok, I'll try to find time for that.
Regards,
Pavel Roskin