On Sun, 13 Nov 2011 20:32:07 -0500
Chet Ramey wrote:
> > This script fails roughly 3% of the time for me, only when running on a
> > loaded system, and then again only when run through "solar". I've tried to
> > run bash manually reproducing the *exact* environment by dumping "env" but
> > no
On Linux, I get an assertion error, using the following example:
$ for i in {1..1000};do read -t .02 = size) /* XXX was i + 2; use i + 4 for multibyte/read_mbchar */
{
input_string = (char *)xrealloc (input_string, size += 128);
remove_unwind_protect ();
add_unwi
On Fri, Nov 11, 2011 at 03:31:02PM -0700, Eric Blake wrote:
> On 11/11/2011 03:23 PM, Peng Yu wrote:
> > I'm not aware if there is any cache mechanism
> > to save the run time (but even so, different terminals still can not
> > see the same cache, hence each terminal has the overhead to create the
This is used in the bash-completion package:
---8<---
# Expand variable starting with tilde (~)
# We want to expand ~foo/... to /home/foo/... to avoid problems when
# word-to-complete starting with a tilde is fed to commands and endi
For example:
declare -A foo
foo['ab]']=bar
will work perfectly fine, but:
declare -A foo
foo=( ['ab]']=bar )
will end with following error:
-bash: [ab]]=bar: bad array subscript
Same with double quotes, or backslash quoting. It's still possible to
quote that right bracket with backslash insi
On 11/14/11 11:15 AM, Michal Soltys wrote:
> For example:
>
> declare -A foo
> foo['ab]']=bar
>
> will work perfectly fine, but:
>
> declare -A foo
> foo=( ['ab]']=bar )
>
> will end with following error:
>
> -bash: [ab]]=bar: bad array subscript
>
> Same with double quotes, or backslash quot
