> On 7/29/10 4:55 PM, Bernd Eggink wrote:
> > It seems that indirect expansion doesn't work with arrays:
> >
> > $ a=(x y z)
> > $ b=a
> > $ echo "${!b[0]} ${!b[1]} ${!b[2]}"
> > x
> >
> > Is that intended? The documentation isn't explicit about it.
> It does, but it doesn't work in the way yo
Techlive Zheng writes:
> Combine with Chet Ramey's reply, a strucure like below would work.
>
> $ c=(a[0] a[1] a[2])
Careful. The elements are subject to filename expansion, so you need to
quote them to be safe.
Andreas.
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 58CA
On 10/2/12 7:38 AM, Techlive Zheng wrote:
>
>
>> On 7/29/10 4:55 PM, Bernd Eggink wrote:
>>> It seems that indirect expansion doesn't work with arrays:
>>>
>>> $ a=(x y z)
>>> $ b=a
>>> $ echo "${!b[0]} ${!b[1]} ${!b[2]}"
>>> x
>>>
>>> Is that intended? The documentation isn't explicit about it.
Chet Ramey wrote:
On 9/28/12 9:54 AM, Yuxiang Cao wrote:
I use ulimit -s to find stack size, which is 8192kbytes. Then I use
valgrind to record the stack size which give me this information.
test.sh: xmalloc: ../bash/unwind_prot.c:308: cannot allocate 172 bytes (8359936
bytes allocated
On Tue, Oct 02, 2012 at 10:01:43AM -0700, Linda Walsh wrote:
> >On 9/28/12 9:54 AM, Yuxiang Cao wrote:
> >>test.sh: xmalloc: ../bash/unwind_prot.c:308: cannot allocate 172 bytes
> >>(8359936 bytes allocated)
> Why shouldn't bash fail at the point it hits resource exhaustion and return
> an error
Chet Ramey wrote:
http://lists.gnu.org/archive/html/bug-bash/2012-05/msg00086.html
The above relies upon a hack to the algorithm -- use *USEFUL* hack
in most cases, but still a hack.
when I type locale I get:
LANG=en_US.UTF-8
LC_CTYPE=en_US.UTF-8
LC_NUMERIC="en_US.UTF-8"
LC_TIME="en_US.U
Greg Wooledge wrote:
On Tue, Oct 02, 2012 at 10:01:43AM -0700, Linda Walsh wrote:
On 9/28/12 9:54 AM, Yuxiang Cao wrote:
test.sh: xmalloc: ../bash/unwind_prot.c:308: cannot allocate 172 bytes
(8359936 bytes allocated)
Why shouldn't bash fail at the point it hits resource exhaustion and ret
Yuxiang Cao wrote:
> I use ulimit -s to find stack size, which is 8192kbytes. Then I use
> valgrind to record the stack size which give me this information.
> test.sh: xmalloc: ../bash/unwind_prot.c:308: cannot allocate 172 bytes
> (8359936 bytes allocated)
> So from the above information I think
Linda Walsh wrote:
> Greg Wooledge wrote:
> >Linda Walsh wrote:
> >>>Yuxiang Cao wrote:
> test.sh: xmalloc: ../bash/unwind_prot.c:308: cannot allocate
> 172 bytes (8359936 bytes allocated)
> >
> >>Why shouldn't bash fail at the point it hits resource exhaustion and return
> >>an error condi
On 10/02/12 14:03, quoth Linda Walsh:
Greg Wooledge wrote:
I see a system message from the original posters program:
Segmentation fault (core dumped)
Finding it is left as an exercise to the reader.
It is noted that many programs catch fatal signals in order
to not leave evidence of their
Linda Walsh wrote:
> Chet Ramey wrote:
> >http://lists.gnu.org/archive/html/bug-bash/2012-05/msg00086.html
> >...Campaign For Rational Range Interpretation...
>
> The next version of bash will have a shell option to enable this
> behavior. It's in the development snapshots if anyone wants to try
>
Hi,
After second thought, I carefully read the bash manual page and find this
information. Functions may be recursive. The FUNCNEST variable may be used to
limit the depth of the function call stack and restrict the number of function
invocations. By default, no limit is placed on the number of
12 matches
Mail list logo
