> On 2/18/15 3:49 PM, Maarten Billemont wrote:
[...]
> > I think the more important question isn't "why does (( behave this way?",
> > but rather "should (( behave this way?".
> >
> > It's probably not reasonable to expect the author to know and take into
> > account that (( arr[$key] )) treats ke
it occurs when an associative array with an empty subscript is modified.
$ ( typeset -A a; x='a[$()]++'; ((x)); )
-bash: a: bad array subscript
-bash: a[$()]: bad array subscript
Segmentation fault (core dumped)
I could live without the error on an empty key to begin with. It can
be hard to prote
On Wed, Feb 18, 2015 at 10:14:10PM +0100, emanuelczi...@cryptolab.net wrote:
> That segfault though:
I confirm that the segmentation fault is in the latest devel version.
dualbus@dualbus ~ % gdb
GNU gdb (GDB) 7.4.1-debian
Copyright (C) 2012 Free Software Foundation, Inc.
License GPLv3+: GNU GPL v
tl;dr: thanks! no reply needed;
Thanks guys. I had a hard time accepting that this is how it's supposed
to work.
I accepted it now. :)
I just hope nobody is going to try to exploit it or something.
That segfault though:
set -x
declare -A ar
key='`echo -n "1">>times.txt`'
((++ar[$key])) # cmd i
On 2/18/15 3:49 PM, Maarten Billemont wrote:
> > also this variant does the same:
> > $ (('ar[$idbad2]+=11'))
>
>
> Because (( and let are essentially equivalent.
>
>
> I think the more important question isn't "why does (( behave this way?",
> but rather "should (( behave this way
>
> > also this variant does the same:
> > $ (('ar[$idbad2]+=11'))
> Because (( and let are essentially equivalent.
I think the more important question isn't "why does (( behave this way?",
but rather "should (( behave this way?".
It's probably not reasonable to expect the author to know and t
On Wed, Feb 18, 2015 at 08:30:31PM +0100, SN wrote:
> > Also, remember to state the version you're using.
> I pasted version in the format printed by bashbug. In case it's not enough:
Yep, you omitted this part though:
Bash Version: 4.3 <- that
Patch Level: 33
Release Status: release
Let's wait to
> Also, remember to state the version you're using.
I pasted version in the format printed by bashbug. In case it's not enough:
$ LANG=C bash --version
GNU bash, version 4.3.33(1)-release (x86_64-pc-linux-gnu)
...
> This particular
> feature seems to behave differently in the -devel branch:
>
>
>
On 2/16/15 12:23 PM, emanuelczi...@cryptolab.net wrote:
> Oh I see, I had no idea that's how it's meant to work. My apologies.
>
> However this case still doesn't work, but maybe I should use single quotes
> all the time?:
>
> this fails(double quotes):
> $ declare -A ar
> $ idbad2="["
> $ let "a
Hi,
found due to a hang in the test suite of gnutls, after debugging I've
extract the example code
launch_server () { sleep 100 & l=$!; trap "kill -15 $l" 15; echo $l; wait
$l; }
launch_server & x=$!
sleep 2
kill $x
which does wait the full 100 seconds with bash 4.3 but with
10 matches
Mail list logo
