Re: Some incorrect behaviour for BASH arrays

On Thu, Aug 31, 2023 at 04:13:09PM +0100, Kerin Millar wrote: > This script is a mess because its functions begin by defining RESULT as an > ordinary, non-array variable (if not yet declared). > > $ RESULT='string' > $ declare -p RESULT # not yet an array variable > declare -- RESULT='string' >

Re: Some incorrect behaviour for BASH arrays

On Thu, 31 Aug 2023 01:12:48 +0700 Victor Pasko wrote: > Hi, > > On my Win-7 64-bit using Cygwin > > > *% bash --version*GNU bash, version 5.2.15(3)-release (x86_64-pc-cygwin) > Copyright (C) 2022 Free Software Foundation, Inc. > License GPLv3+: GNU GPL version 3 or later

Re: Some incorrect behaviour for BASH arrays

On Thu, 31 Aug 2023 19:39:09 +0700 Victor Pasko wrote: > Thanks for prompt response. But see my comments below. > > Well, instead of the following line > > RESULT='' > > done > > declare -p RESULT > > without initialization, because otherwise I got the following error "-bash: > declare: RESU

Re: Some incorrect behaviour for BASH arrays

Thanks for prompt response. But see my comments below. Well, instead of the following line RESULT='' done declare -p RESULT without initialization, because otherwise I got the following error "-bash: declare: RESULT=: not found". And after deleting/commenting the following fragment in badrev

Re: Some incorrect behaviour for BASH arrays

On Wed, Aug 30, 2023, at 2:12 PM, Victor Pasko wrote: > Attached please find bug.bash to reproduce incorrect BASH behaviour for > BASH arrays > and look at ways to run it Your tests are flawed. The lines you use to inspect RESULT... > badsed() { # just array indexes are used for RESULT > ... >