Repeated in the bash-4.0.38 and bash-4.1.7 by the script;
#!/bin/bash
typeset -Ai s
y='*'
z='['
s[$y]=1
s[$z]=2
(( s[$z] = s[$z] + ${s[$y]} ))
(( s[$y] = s[$y] + ${s[$z]} ))
[[ ${s[$y]} = 4 ]] && echo "ok"
FIX: added check;
diff -up bash-4.1/variables.c.Ai bash-4.1/variables.c
--- bash-4.1
Huh. Triple redirect... Thanks!
On 7/26/2010 5:53 PM, Chet Ramey wrote:
> On 7/26/10 6:25 PM, Linda Walsh wrote:
>> I don't know if there's an easy way, but if not would you consider an
>> RFE --
>>
>> Is there a syntax for a mult-var assignment, ala:
>> (a b c d)=(1 2 3 4)
>
> Yes.
>
> read
On 07/27/2010 02:35 PM, Greg Wooledge wrote:
> On Tue, Jul 27, 2010 at 01:44:26PM +0200, Christoph Dittmann wrote:
>> What I was going for was a script which executes another command with a
>> timeout.
>
> http://mywiki.wooledge.org/BashFAQ/068
The process I want to put under the timeout does not
On Tue, Jul 27, 2010 at 01:44:26PM +0200, Christoph Dittmann wrote:
> What I was going for was a script which executes another command with a
> timeout.
http://mywiki.wooledge.org/BashFAQ/068
http://mywiki.wooledge.org/XyProblem
On Mon, Jul 26, 2010 at 04:27:30PM -0500, Peng Yu wrote:
> Could you
> please let me know when to use printf instead of echo?
There is never any need to use echo. printf does everything echo does,
and does it better -- but people are comfortable with echo, because it's
simple, and they've been tr
On 07/27/2010 02:05 PM, Eric Blake wrote:
> On 07/27/2010 05:44 AM, Christoph Dittmann wrote:
>> What I was going for was a script which executes another command with a
>> timeout.
>
> If you can assume the presence of GNU coreutils, use timeout(1). Much
> nicer for this particular task.
Thanks,
On 07/27/2010 05:44 AM, Christoph Dittmann wrote:
> What I was going for was a script which executes another command with a
> timeout.
If you can assume the presence of GNU coreutils, use timeout(1). Much
nicer for this particular task.
Otherwise, I did not review your script for accuracy.
--
On 07/27/2010 12:05 PM, Andreas Schwab wrote:
> If you want to kill the whole background job you need to enable job
> control (set -m) and call kill with the job specifier instead (kill %2
> in this case).
>
>> How can the wait call affect a job it's not supposed to wait for?
>
> It's a simple ra
Christoph Dittmann writes:
> Why is "sleep 5" still running in the second case even though the job
> received SIGTERM and is known to the job control as "terminated"?
Try adding "ps f" before the wait command to see the difference in how
bash executes the two cases. In the case without the brac
