bash 5.2 regression in optimize_connection_fork
Configuration Information [Automatically generated, do not change]:
Machine: x86_64
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS: -g -O2
uname output: Linux kbuild 5.19.0-23-generic #24-Ubuntu SMP PREEMPT_DYNAMIC Fri
Oct 14 15:39:57 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux
Machine Type: x86_64-pc-linux-gnu
Bash Version: 5.2
Patch Level: 9
Release Status: release
Description:
OVN makes use of GNU autotest for its testsuite. This in turn is a
heavy user of bash.
For some reason, when the 'ovn-controller incremental processing' test is
executed using bash 5.2 on Debian experimental or Ubuntu Kinetic/Lunar, the
`eval` [0] in the `counter_delta_` function misinterprets successful execution
of commands [1], leading to a false negative for the 'ovn-controller
incremental processing' test [2].
Backporting the bash 5.1 package from Jammy, or compiling bash 5.1 from
upstream sources and rerunning the test makes it succeed.
This does come across as a regression in bash.
0:
https://github.com/ovn-org/ovn/blob/a042aa23e79a0d36f1ce7b0ccfcf0a5995b045cd/tests/ovn-performance.at#L116
1:
https://github.com/ovn-org/ovn/blob/a042aa23e79a0d36f1ce7b0ccfcf0a5995b045cd/tests/ovn-performance.at#L479
2:
https://github.com/ovn-org/ovn/blob/a042aa23e79a0d36f1ce7b0ccfcf0a5995b045cd/tests/ovn-performance.at#L227
Reported-At: https://bugs.launchpad.net/bugs/1997093
Repeat-By:
I have unfortunately not been able to create a simple reproducer but
the following steps will give you a reproducing environment:
git clone https://github.com/ovn-org/ovn.git
cd ovn
git submodule update --init --recursive
cd ovs
./boot && ./configure && make
cd ..
./boot && ./configure && make
make check TESTSUITEFLAGS="837"
Fix:
Applying this patch, reverting a change made to
optimize_connection_fork in bash 5.2, fixes the problem for me:
diff --git a/builtins/evalstring.c b/builtins/evalstring.c
index 264a836b..36ecd310 100644
--- a/builtins/evalstring.c
+++ b/builtins/evalstring.c
@@ -132,8 +132,7 @@ optimize_connection_fork (command)
if (command->type == cm_connection &&
(command->value.Connection->connector == AND_AND ||
command->value.Connection->connector == OR_OR ||
command->value.Connection->connector == ';') &&
(command->value.Connection->second->flags & CMD_TRY_OPTIMIZING) &&
- ((startup_state == 2 && should_suppress_fork
(command->value.Connection->second)) ||
- ((subshell_environment & SUBSHELL_PAREN) && should_optimize_fork
(command->value.Connection->second, 0
+ should_suppress_fork (command->value.Connection->second))
{
command->value.Connection->second->flags |= CMD_NO_FORK;
command->value.Connection->second->value.Simple->flags |= CMD_NO_FORK;
Re: bash "extglob" needs to upgrade at least like zsh "kshglob"
2022年11月18日(金) 2:11 Chet Ramey : > "If a pattern ends with an unescaped , it is unspecified whether > the pattern does not match anything or the pattern is treated as invalid." > > Bash uses the former interpretation. If "the pattern is treated as invalid" > means trying to literally match the open bracket and going on from there, > your interpretation is valid as well. The standard doesn't use that > language in other places it specifies to treat the bracket as an ordinary > character to be matched literally, however. Thank you for the explanation. I haven't been considering the consistency with the treatment of the slashes outside the bracket expression. I think I need to adjust the treatment of the slash in my new engine by introducing e.g. a special flag for . Thank you. -- Koichi
Re: bash "extglob" needs to upgrade at least like zsh "kshglob"
2022年11月18日(金) 6:29 Chet Ramey : > The same is true for ranges. If either the first character or the second > character in the range is a slash it should cause the bracket to be matched > literally. > > Incidentally, I made an additional change so that an incomplete range > expression causes the bracket to be matched literally. > > Thanks for the discussion. I attached an updated version of the patch I > sent yesterday. I wasn't quite as aggressive as you with macros. Thank you for the new version of the patch. I have tried it. Thank you for considering the change to the incomplete range in the bracket expression. -- Koichi
Re: [PATCH] glob: add shopt globmtimesort to sort globs by mtime
On 11/16/22 12:35 PM, Evan Gates wrote: On Mon Nov 14, 2022 at 1:00 PM MST, Chet Ramey wrote: On 10/3/22 2:56 PM, Evan Gates wrote: --- There is currently no good way to sort files by mtime in the shell. It's possible to do so with an ls that supports -t, but parsing ls is problematic. Thanks for the patch. There are some good things here, usable stuff, but I think I'll look at a more general approach for the next version. If you're taking care of it, that's awesome. Whatever I come up with will appear in the devel branch. I haven't started any `next version development' cycle yet, though. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
Re: "cannot execute binary file" error with Bash 5.2
On 11/16/22 5:19 PM, Loïc Yhuel wrote: https://savannah.gnu.org/support/index.php?110744 I attached the patch I applied. It works, thank you. Btw, I didn't search on savannah since https://www.gnu.org/software/bash/manual/html_node/Reporting-Bugs.html doesn't mention it. Good idea; I should add it to the manual. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
